CODEWITHSUNDEEP
gitversion-controlworkflow
Borek Bernard
Borek Bernard

Reputation: 53331

Two parallel branches in Git, how to work on "future" but commit basic fixes to "master"

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):

How do people deal with this workflow?

Upvotes: 4

Views: 2080

Answers (3)

Jonathan Ruiz
Jonathan Ruiz

Reputation: 300

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.

Upvotes: 0

Bert F
Bert F

Reputation: 87573

  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.

Upvotes: 1

VonC
VonC

Reputation: 1327294

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.

Upvotes: 2

Related Questions