Cherry picking commits is generally best for when you have a lot of changes and you need only some of those changes to move over. Merging branches is the standard approach for when you want to develop some changes and then update a second environment with the “verified stable” changes. From your description, it sounds like merging branches is what you would want to use.
Just to be certain, let me be more specific. It sounds like you do the following:
- You make changes to the codebase to add new features on a branch (let’s call it
- When the new features have been thoroughly tested, you need to add that code to the code that’s in the field (on a branch called
field for example)
Now currently, you find all the commits that were added to the
lab branch and
git cherry-pick them into the
field branch. I assume you do this because, at some point in the past, you did
git merge and either clobbered the slight code changes for the field or dealt with some merge conflict when things changed in both places?
To be clear, both approaches work. But
git merge is easier especially when there are no merge conflicts. You can significantly reduce the chance of merge conflicts if you extract the code differences into different files. For example, you could use a different configuration file in the field versus in the lab. Or you could load different code based on whether a certain environment variable existed (like
This allows you to use the much simpler
git merge process and still not have to deal with merge conflicts nearly as much.
Let us know if you have more questions.