2

I've checked lots of questions here in Stack, but didn't figure out how can I use the Gitflow Workflow in my team.

Here are our branches:

workflow

In my team we have three main branches: master, test and dev. All feature branches are being branched off of dev. Once they're a somewhat stable we branch them back in dev (we're maintaining that dev server to allow some non-developers to perform some tests before send to the customer Q&A).

So, when the feature is stable enough to go to the customer test, we merge the branch dev to the branch test. Once approved, the test branch is merged into master.

My issue is: in some cases we could have 4 different branch features that were merged into dev and then into test. But, for some reasons, one of the features in test should go to production, while the others 3 should wait for customer validation.

How can I send to prod (merge into master) only the approved feature, and keep the others 3 in test without carrying all its commits during the merge?

Mad Physicist
  • 107,652
  • 25
  • 181
  • 264
Weder Ribas
  • 361
  • 6
  • 16
  • 1
    Use [cherry picking](https://git-scm.com/docs/git-cherry-pick) – Mad Physicist Feb 22 '17 at 19:50
  • To clarify, you have features 1, 2, 3, 4, all of which made it to **dev** and **test**. Now you only want feature 4 to go from **test** to **master**, keeping everything else as-is? – Mad Physicist Feb 22 '17 at 19:51
  • Also, that merge with two purple dots and a yellow dot going into another yellow dot looks a bit shady. I'm not sure you can merge three commits together like that, but I could be wrong. – Mad Physicist Feb 22 '17 at 19:54
  • @MadPhysicist Yes, in this case I'd like to send only the feature 4 to production and keep 1,2,3 yet into test waiting for a new release. (Just to clarify that the feature 1, 2, 3 and 4 could have many commits each one). – Weder Ribas Feb 22 '17 at 19:59
  • OK. One final question. Do the fixes that happen in **dev** and **test** get commited on a per-feature basis. I.e., can you point to a set of commits in **test** and say, these are the exact commits that represent feature 4 with all modifications that need to go to master? – Mad Physicist Feb 22 '17 at 20:01
  • @MadPhysicist I'm quite sure that the answer is yes. Once we're always using merge with *--no-ff*, I can figure out the exact point where each feature was branched into **test**. So, each bunch of commits among the merges should belongs only to each feature. – Weder Ribas Feb 22 '17 at 20:06
  • @MadPhysicist OT but that's kosher; it's called an octopus merge. [See this infamous 66-parent example from the Linux kernel](http://marc.info/?l=linux-kernel&m=139033182525831). – Pockets Feb 22 '17 at 20:11
  • @WederRibas this is a classic use case for `git cherry-pick`: identify the commits on `test` which introduce feature 4 and cherry-pick them into `master. From the man page: "Given one or more existing commits, apply the change each one introduces, recording a new commit for each." – Pockets Feb 22 '17 at 20:16
  • 1
    @Pockets. That's just neat. But I'd hate to be anything but a spectator :) – Mad Physicist Feb 22 '17 at 21:50

1 Answers1

0

This looks like a standard use-case for git cherry-pick. This is a command that lets you apply selected commits and ranges of commits to a different branch. Since you said that you know exactly which set of commits you need to apply, it is a perfect tool for the job.

As of git 1.7.2, you can cherry-pick a range of commits. Say feature 4, which needs to be applied to master, is represented by commits with SHA1s 12345 through abc123. Then you just do

git checkout master
git cherry-pick 12345^..abc123

The first commit must be the earlier one. ^ takes care of the fact that the starting end is exclusive in the range. See https://stackoverflow.com/a/1994491/2988730 for details.

For prior versions of git, you would have to process each commit individually:

git checkout master
git cherry-pick 12345
git cherry-pick df998
...
git cherry-pick abc123

If it turns out that you do need to break up some of your commits, use git cherry-pick -n to check out the patch and then use git add -p to get the chunks you want out of it, as described in detail here.

It is also possible to use git rebase --onto to accomplish the same task. This has the advantage that you can do it interactively, i.e., select the commits, modify their messages and have more control over the content than with cherry picking. The answer linked above explains how to do this in detail.

Community
  • 1
  • 1
Mad Physicist
  • 107,652
  • 25
  • 181
  • 264