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?

2 Answers
2

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.

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.

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 WhiteNov 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 JenningsNov 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.