Re: How to handle a git repository with multiple branches
- From
- Joshua Juran <jjuran@gmail.com>
- Date
- Aug 26, 2010, 13:09 UTC
- Message-ID
- <D36A67AE-3477-4D8D-A424-6413D8C4E70C@gmail.com>
- In-Reply-To
- <AANLkTimW-SQi1eprxTPXxF85SBO4d5MU13=dsboNNrzd@mail.gmail.com>
On Aug 26, 2010, at 4:53 AM, Erez Zilber wrote:
Show 22 quoted lines
> 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?
Off the top of my head, store each patch in its own branch, based off of a commit common to both branch_1 and branch_2. Then merge patch branches into release branches as appropriate. You might consider also doing this for patches unique to a release, not just the common ones.
Josh