gitgit-flow

Git Release flow: deploying features not in commit sequence

I am starting a new project and would like to use Release Flow http://releaseflow.org/

I would have a "main" (master/production) branch, which will represent latest project state. To make a releases I would use tags.

Situation: Let's say in Jira 2 developers will work on 2 different tasks. Developer A working on medium priority task A, developer B on high priority task B. Developer A finishes his big task first, merges it to "main", then same does dev. B.

Then main branch wil look like: enter image description here

Now, since task B is more important, it is being tested first, and now ready to be deployed to prod. But task A is not yet fully tested, so not ready to be deployed.

The question is: how would I make a deployment tag to include only task B, not task A?

Updated:

  1. In this situation solution provided by @Ôrel (using tags on latest commit in brach "task B") works very well.
  2. But what if then another "task C" is ready to be deployed, but "task A" is still in testing? How would I create a tag for "task B" + "task C", but without task A?
Solution

  • One way to restate your question could be:

    After merging multiple undeployed features into main, how can I release some of those features but not all of them?

    The following concepts come to mind:

    1. Revert. If this doesn't happen that often, create a release branch and revert the feature(s) you don't wish to release (yet).
    2. Change workflows. If this happens often, consider using a different workflow, such as gitworkflow which is designed for this. The idea is to have a branch such as next which is where you do preliminary integration testing to work out the kinks, and then you merge only the features you like into a long lived shared branch. The key here is that you periodically reset next (perhaps to main) to remove all of the throwaway test code.
    3. Add a validation step. Take a hybrid approach. You can still use your current flow, but use a next branch (as described in option 2) to do preliminary testing so that by the time you merge into main you decrease the chances that you'll need to revert any features from a release. Note this option is similar to Ôrel's comment. You may be able to skip having a next branch and instead build and fully test the feature branch before it's merged anywhere.