4

How can I find the source branch commit for a feature branch after the branch has been merged?

Consider a git workflow with a master branch and release branches. Master continues forward to the next release. Bug fixes are applied to the release branch, but must be back ported to the master branch.

The feature branch is created on the release branch, reviewed, and merged into the release branch. The feature branch must now be rebased to the master branch to apply the fix to master as well. However,

git rebase --onto master release

Results in 0 commits. This makes sense as release has moved forward and 

git merge-base HEAD release

results in HEAD (merge-base being used internally to determine the rebase starting point). Therefore, the rebase results in rebasing nothing. Not useful.

I can use git log to determine where I think the branch point might be, but I'd really like to know better where the branch point is most likely. The goal is better automation for this common situation.

An simple example tree (trees are seldom this simple. :) :

*    5caf21e (release) Merge pull request #689 from ...
|\ 
| *  9f0f210 Bug 1123: Fix bug
| *  bb6b3fa Bug 1123: Reproduce bug
*    077afe0 Merge pull request #688 from ...
|\ 
| *  e750974 (feature/bug1154) Bug 1154: Fix bug
| *  98194b9 Bug 1154: Reproduce bug
*    cabb4d2 Merge pull request #681 ...
|\ 
| *  a10c992 Bug 1110: Bug fix
| / 
*    7caacee Merge pull request #673 ...

I want to rebase feature/bug1154 at e750974 to the master branch. This branch has been merged and the release branch has moved on as well.

git rebase --onto master release feature/bug1154

results in no commits being applied.

I really want to do 

git rebase --onto master cabb4d2 feature/bug1154

How do I find cabb4d2 using git commands? Something that can be automated and easily explained to others, without having to interpret git log by hand.

Bill Door
  • 18,272
  • 3
  • 32
  • 37
  • Wait, `cabb4d2` is supposed to be the ancestor of `feature/bug1154` in that graph? So is `077afe0` the commit where that feature branch is merged into the release branch? – Useless Nov 19 '14 at 19:30
  • @Useless correct. This is a graph that would be the result of `git log --oneline --graph --decorate` (my alias for `git ll`). – Bill Door Nov 19 '14 at 19:43
  • What commit would master be pointing at in your example tree? Maybe an ancestor of 7caacee or a descendant of 5caf21e? You say "master continues forward to the next release." Does that mean master is the home of ongoing development for a forthcoming release and the release branch is bug fixes and maintenance? If so, what's a feature branch doing on the release branch? – gatkin Dec 03 '14 at 22:42
  • @gatkin, you are correct, master is forward development, release is bug fix and maintenance. The use of feature as a branch name is just convention. – Bill Door Dec 03 '14 at 23:53

1 Answers1

1

I don't entirely understand the situation (see my comments) but I'll take a stab at it.

How to back port a feature?

The usual command to backport a commit or two is git cherry-pick. But based on your workflow I don't think that's what you want.

Bug fixes are applied to the release branch, but must be back ported to the master branch

If the master branch is the work being done for a future release and the release branch is maintenance/bug fixes, then that's just a merge. If people are supposed to merge each bug to master as they fix them in release, then whoever fixed bug 1123 may have already merged 1154.

How can I find the source branch commit for a feature branch after the branch has been merged?

Technically, Git doesn't record that anywhere, even before a branch is merged. The command git merge-base --fork-point can deduce it, but only if the local reflog has enough history.

How do I find cabb4d2 using git commands?

If you know the merge point was 077afe0, then git merge-base 077afe0^1 077afe0^2

Taking a step back, it isn't clear from your question what's special about feature/bug1154. Whatever process was in place for 1110 and 1123, that's what should be done for 1154. And if master is pointing at a descendant of 5caf23e, then it has already been merged.

gatkin
  • 1,902
  • 12
  • 12
  • We stopped merging from release branches to the master branch because the complexity just became too high. In addition, determining when to merge became a problem as well. Thank you for the fine answer. – Bill Door Dec 05 '14 at 20:36
  • @BillDoor You're welcome. Note that if the feature branch was merged to the release branch more than once, or if there was cross-merging, the answer to your last question becomes far more difficult. See [this question](http://stackoverflow.com/questions/1527234/finding-a-branch-point-with-git) for more. It would be nice if `merge-base` had a `--choke-point` option or something. – gatkin Dec 05 '14 at 20:57
  • I found that as well. One of the sample feature branches I tried, had this problem. Took me a minute to work out why. So, while not a perfect solution, your's comes very close. – Bill Door Dec 05 '14 at 21:24