How to handle a git repository with multiple branches
- From
- Erez Zilber <erezzi.list@gmail.com>
- Date
- Aug 26, 2010, 11:53 UTC
- Message-ID
- <AANLkTimW-SQi1eprxTPXxF85SBO4d5MU13=dsboNNrzd@mail.gmail.com>
Hi,
My repository has several branches. Each branch is for a separate code release. Let's assume that I have a branch for V1.0 (branch_1) and a branch for V2.0 (branch_2).
Some commits are relevant only for branch_1, some are relevant only for branch_2 and some are relevant for both. For the commits that are relevant for both branches, I thought about the following solutions: 1. Put these common commits in branch_1 and merge branch_1 into branch_2. This is bad because it will also merge commits that are relevant only for branch_1. 2. Cherry-pick the common commits from branch_1 to branch_2. This is also bad because the commit ID changes, and in case of conflicts, git is unable to tell that these 2 commits are actually the same commit. This makes it very difficult to track the changes between branches.
Since there are several other developers and sub-maintainers in this project which are rebased on both these branches, I don't want to change the git history of my branches because when I do that, sub-maintainers and developers lose the reference to their base.
I'm looking for a better solution. Is there any best-practice solution?
Thanks, Erez