4

This is probably a common scenario but there are so many Git workflow questions here on SO that I couldn't find an answer for my exact question. Which is:

I have a master and future branches in Git that live in parallel. future contains some future features while master is the current version (approximately).

When developing a future feature, I often encounter a situation where I need to make a fix that needs to go to master. What I do now:

  1. Stash work in progress in future
  2. Switch to master
  3. Fix code in master
  4. Switch to future
  5. Merge from master
  6. Stash pop

In some cases, where the fix is better tested in the future branch, the process becomes even more cumbersome, consisting of making the change in future, committing it there, switching to master, cherry-picking from future, checking out future, reseting future and merging from master in the end.

There must be a better way but I can't figure it out. Approaches that wouldn't work (I believe; correct me if I'm wrong):

  • Merging from future to master. I don't want all commits from future in master.
  • Committing everything to future and then cherry-picking certain commits to master. This alone would not be enough because future merges from master to future would cause duplicate commits (or maybe even conflicts?). Maybe I could create opposite commits in future to those cherry-picked to master but that feels messy.

How do people deal with this workflow?

Borek Bernard
  • 50,745
  • 59
  • 165
  • 240
  • Hi have you found a solution for your problem? I hit a similar problem https://stackoverflow.com/questions/65210198/cherry-pick-a-commit-to-master-seems-unavoidable-in-my-case-how-do-i-mitigate-i – Qiulang Dec 09 '20 at 03:48
  • @Qiulang I now prefer feature toggles over long-running Git branches. – Borek Bernard Dec 09 '20 at 16:57

3 Answers3

2

If you are alone developing on the future branch, you could rebase it on top of master instead of merging master to it.

And since git 1.8.4 (July 2013), git rebase has learned to "autostash": see this answer.

git checkout future
git rebase --autostash master

For the opposite case, cherry-pick remains the main option.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • "For the opposite case, cherry-pick remains the main option." Do you mean that I should commit to `future` and later cherry-pick to `master`? Does Git remember from where it cherry-picked so that later commits are not affected by the possible duplicity? Or should I revert commits in `future` that got cherry-picked to `master`? – Borek Bernard Dec 02 '14 at 15:55
  • @Borek that is the main issue of cherry-picking: it adds duplication (see http://stackoverflow.com/a/2628915/6309). I would prefer, if possible to rebase interactive future, in order to put first those commits (and merge to master those first commits of the future re-oredered branch), instead of using cherry-picking. – VonC Dec 02 '14 at 15:58
1
  1. Stash work in progress in future
  2. Switch to master
  3. Fix code in master
  4. Switch to future
  5. Merge from master
  6. Stash pop

There must be a better way but I can't figure it out.

I used to do that process, but after I found I needed to do switch back and forth often, I changed to simply having 2 working directories - one for working on "master" branch and one for "future" branch ("develop" in my case). Both dirs used the same remote repo/origin and the two working dirs had each other as remotes too. Two dirs eliminated the need to stash save/pop before/after switching branches.

I also didn't feel the need to pull the fix from master into future (step 5) right away unless there was a reason I had too. Normally, I would finish the current feature for future first and delay merging from master until convenient.

Bert F
  • 85,407
  • 12
  • 106
  • 123
  • That's a reasonable workflow, and certainly useful for some scenarios. My trouble is that I need to merge those `master` changes almost immediately so that's still quite a PITA. (I might leave the branching model entirely and use some other technique like feature toggles.) – Borek Bernard Dec 03 '14 at 12:46
0

You can just create a new branch for the fix.

  • Merge it in master
  • Merge it in your branch if it's not convenient to do it at that very moment directly to master.
  • Other developers could merge it in their own branches.
Jonathan Ruiz
  • 180
  • 1
  • 7