11

I've been using git for a while for my one-man developments, but I haven't run into any tricky branching issues until now and I seem to have forgotten something fundamental that I no doubt "knew" just after reading the Pragmatic Version Control Using Git Book..

I'm often several releases ahead of what is actually published on my website, so that when a bug report comes in, I only apply them to the current master branch rather than fixing them in the next released version. Of course, I'd like to change that to get fixes out quicker.

Let's say 1.0 was just released, 1.1 is going to be released soon, but I'm already working on 1.3, e.g. 

1.0 - released  
1.1 - finished  
1.2 - finished  
1.3 - in development

A bug report comes in.. usually this would be fixed in 1.3, but how do I fix it in 1.1 instead?

As far as I am aware in svn and other "traditional" source control systems, I would need to branch B.1.1 and B.1.2 and apply the changes to each branch in turn, then build from each branch and finally apply the fix to the master branch.

I seem to remember that git, however, does something clever: I branch B.1.1, make the changes there, do {something} and B.1.2 and the master branches are automagically updated with the fix. Is this possible or did I imagine {something}?

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
Frank R.
  • 2,328
  • 1
  • 24
  • 44

2 Answers2

6

The right way in this case would be to:

  • make sure you have B1.1 and B1.2 created (to isolate final fixes in their respective branch)
  • apply your patch on master
  • cherry-pick that commit to B1 and B2

As mentionned in this thread, that would:

ensures master doesn't regress with respect to an older branch. (Do not use merge unless you want to merge all changes from one branch to another, rather than just the single commit you mention.)

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks. I didn't even know "git cherry-pick" existed.. but that's still basically the same "make lots of branches and fix every branch individually" workflow. I don't fully understand (or begin to understand) rebase properly, but would it not be possible to fix the problem on the master branch, commit it and then use rebase to re-order the commits on the master branch, so that the fix occurs before the 1.2 release. Would that mean that the change is "inherited" by 1.2 and the 1.3 development versions? – Frank R. Dec 04 '09 at 16:26
  • That could work (rebase -i or rebase interactive) provided you did not push those branches anywhere: you would rewrite history (actually replacing an history by a new one) of master. Still, B1.1 and B1.2 can still be there for 1.1 or 1.2 specific fixes. – VonC Dec 04 '09 at 17:10
  • Thanks. I'll try to rebase next time. I don't push to another repository (I use git as a private repository only), so the fast-forwarding isn't a problem. – Frank R. Dec 04 '09 at 17:36
  • What is the proper way of making a hotfix commit here? Is it to let the developer make multiple commits then do merge with --no-ff, or better to do squash? If the former, then how to cherrypick this kind of commit? I don't it's not straight forward. – sancho21 Mar 27 '17 at 11:20
  • @sancho21 (7+ years later) applying an hotfix is often through cherry-pick. As mentioned in the answer: "Do not use merge unless you want to merge all changes from one branch to another, rather than just the single commit you mention." – VonC Mar 27 '17 at 11:24
  • @VonC, I'm still confused in the upstream-first way of work. Supposed there are 3 repos: Linus', His guardian's, Mine. I found a crucial problem in my repo which probably also happens in Linus'. So, I branch out from Linus', make some commits (sha1=a, b, and c), then ask for a merge request to him. He merge my changes with --no-ff mode (resulting sha1=d). His guardian will do a cherrypick againts which one? Is it a, b, c or.... d? Cherrypicking from d is not possible. – sancho21 Mar 27 '17 at 11:32
  • @sancho21 that kind of workflow (and the context of the OP) was *not* for a lieutenant workflow (https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow). In a Linux-like lieutenant-based workflow, you would prefer merging. – VonC Mar 27 '17 at 13:41
  • @VonC, honestly I'm using Gitlab, but Gitlab suggests us to use up-stream first workflow. Now forget about any workflow, my question is simple: Should I do cherrypick one by one for my scenario above (a, b, c)? – sancho21 Mar 29 '17 at 03:07
  • @sancho21 yes, you can cherry-pick. If those commits are in a sequence, you can cherry-pick them in one operation: http://stackoverflow.com/a/1994491/6309 – VonC Mar 29 '17 at 04:40
0

What about in this case fixing on B1.1, merging B1.1 into B1.2, then B1.2 into B1.3?

Marius K
  • 498
  • 5
  • 6