Git: applying changes to two branches

Question

I have two branches in my repository (for the purposes of this question): master and performance_testing. I have received changes for the master branch. I need to put them into performance_testing as well. I need to keep the two branches existent and separate, so merging would not be appropriate. I guess I could introduce the changes in one branch and commit, then do the same in the other branch. But this seems to be error-prone, and I would think that git would have some way to do this more directly. How do I do this?

Answer 1

The best approach would be creating a feature branch for the changes and merging it at the end in master and performance_testing. Cherry-picking is considered as an anti-pattern.

To create the feature branch, first find the most recent common ancestor of 2 branches:

git merge-base master performance_testing

Then create feature_branch using the output of the previous command:

git branch feature_branch <output of merge-base command>

Switch to feature_branch branch, make the changes and merge it at the end in master and performance_testing.

If you have changed same files in 2 branches you will get a conflict. It's inevitable, even with cherry-picking, but easy to solve.

The advantage of this approach over cherry-picking is that you will get an uniformed log, with the same commit hashes on both branches.

Answer 2

Often what you would do in this scenario is cherry picking, which involves applying only a sub-set of the commits of one branch onto another.

For example, you have commits A, B, C, D, E, F on master and you wish to bring commits B, C and D into performance_testing:

git checkout performance_testing
git cherry-pick B^..D

Or you can list individual commits in multiple, individual cherry-pick commands. This is useful when you don't necessarily want a continuous series of commits. For example:

git cherry-pick B D

Note that B comes before D in the history.

For more detail, see: How to cherry-pick multiple commits (which also includes some great diagrams I won't poach into this answer).

Yes, there are many different options to choose from. This is a basic and common solution which the reader can choose to apply now that they understand how it works. git rebase --onto is another option, as is different branch management, but without a very specific scenario in mind, cherry-picking should get the most mileage.

Answer 3

I need to keep the two branches existent and separate, so merging would not be appropriate.

That doesn't necessarily follow; after a merge both branches still exist and are still separate. The case where merging would be inappropriate is if each branch currently contains changes that cannot be in the other.

When you say you "received changes for the master branch", what exactly does that mean? If you mean someone pushed changes to the origin/master, then that limits your options. What would otherwise be the best solution (creating a branch at a merge base between master and performance_testing, applying the changes there, and then merging that branch into both master and performance_testing) would become complicated by the need for a history rewrite affecting already-shared commits (to remove the direct application of the changes to master).

If the changes were directly applied to master, and master contains changes that cannot be brought into performance_testing: then unless coordinating a history rewrite is acceptable, your remaining option probably is to cherry-pick the change. In my opinion cherry-picking is recommended way to often and has significant drawbacks, but if you've ruled out every other solution then this is what remains.

Answer 4

You can use git cherry-pick to apply (copies of) one or more commits onto a new branch.

The new commits will "have the same effect as" the originals (same diff, same message etc.) but are otherwise independent.