Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am using git to manage tweaks to a distribution and generate an ISO for each flavor. I currently have 4 branches not including master. What is the best way to manage these branches as they share files and I want to easily move changes back and forth between branches. I am using cherry pick to pull changes to each branch. However, I have to do that for each commit I want and look at the logs for each branch.

What other options to I have, any other ideas as to how to best organize these branches?

share|improve this question
up vote 2 down vote accepted

Each distribution branch should be originally branched off of the master branch, then add commits directly to the distribution branches to make them unique. To keep them up to date, occasionally merge changes from master into the distribution branches.

For example, if your distribution branches are one and two, then the following commit graph shows that commits are made against the master branch, then the changes are merged into each branch.

distribution branches with changes merged in from master

# Create distribution branch and make it unique
git checkout -b one master
work... work...
git commit

# Make some changes on master
git checkout master
work... work...
git commit

# Merge the changes into the distribution branch
git checkout one
git merge master

I have used this strategy when a master branch contained generic application settings, but I wanted to keep production environment settings in source as well. Each production environment had the specific settings committed, and when I wanted to update a production environment I would first merge master into the production branch.

share|improve this answer
I have been doing this method, but I am testing just having different directories and using a tool like meld to merge changes. This approach above does work well if you stay current, but I had a bunch of changes for about 1 month of work. When I merged and rebased (to remove commits I didn't want), it seemed that I lost a bunch of stuff. – Walter White Nov 28 '11 at 21:06
@Walter I'm not sure why that might have happened, but you might benefit from using git-rerere. You can use this command to occasionally record merge resolutions so that when you finally decide to perform the merge, a lot of the merge conflicts can be automatically resolved. – Stephen Jennings Nov 28 '11 at 23:39

The strategy I would use would depend on the difference between the various branches, and the types of changes being made that need to be propagated across all the branches.

If the differences are relatively constant and made in a part of the code base that doesn't change very often (like setting variables to different values in a Makefile, while most development is happening in source code files), I would set up the branches, do the development in master, and then use git rebase master in the branches whenever I needed to update them.

However, if the differences between the branches are themselves fluid, I'd merge and cherry-pick as needed.

share|improve this answer
I was doing it this way, how do you recommend selectively merging commits? When I used rebase, I had issues with losing changes that I could have sworn were there. – Walter White Nov 28 '11 at 21:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.