Home/ Questions/Q 8011011
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T18:54:22+00:00

I’ve been trying to wrap my head around git branching models. I’ve been looking

  • 0

I’ve been trying to wrap my head around git branching models. I’ve been looking at http://nvie.com/posts/a-successful-git-branching-model/ for some ideas and coming from Subversion one thing I was really looking forward to was making a change in a single place and merging it to all the branches that needed it. In Subversion, we ended up doing to much copy of code around.

However I still don’t get this completely. Here is a standard type of workflow that I have and it will always come up with conflicts.

# create new version branch
git checkout master
git checkout -b v3
vim pom.xml  # change branch version to "3.1-SNAPSHOT"
git commit -a
git checkout master
vim pom.xml  # change master version to "4.0-SNAPSHOT"
git commit -a

So the master is at 4.0-SNAPSHOT and the branch is at 3.1-SNAPSHOT.

Not I want to create a hotfix on the branch and move it to the trunk.

git checkout v3
git checkout -b hotfix
vim file.txt  # make a bugfix change
git commit -a
git checkout v3
git merge hotfix  # this works fine
git checkout master
git merge hotfix  # this has a conflict since both branches have changed the version

I understand why its happening and it makes sense. Is there a better way of doing this?

I read about cherry-pick, which I tested and does work:

git checkout v3
git cherry-pick a518b0b75eaf28868
git checkout master
git cherry-pick a518b0b75eaf28868

However, that doesn’t seem like the “correct” way to handle this. Any suggestions?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Really, your answer is dependant on if you want your trees to be based on the same history… For example, 4.0 is based on the latest 3.X + all of the changes in 4.0…

    Personally, I don’t recommend it once you decide to start a new branch(s) for a new version(s). At a give point of time, the software is taking a different direction, so your branches should also.

    This leaves git cherry-pick as your ideal solution. Make the change in whatever branch makes the most sense, and then cherry pick it to the older versions. This is the same as if you had checked out the old branch and manually applied the same change, and made a new commit. It keeps it clean and to the point.

    Git merge or rebase are going to try to integrate the branches history together, each in their own way, which I suspect you don’t want when backporting bug fixes, etc…

    • 0