From: Joshua Juran Date: Thu, 26 Aug 2010 13:09:13 GMT Subject: Re: How to handle a git repository with multiple branches Message-ID: In-Reply-To: On Aug 26, 2010, at 4:53 AM, Erez Zilber wrote: > 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