Consider using separate settings files for dev and production environments
cherry-pick
is usually the best and easiest option to merge only specific commits into a line of development. If you have to constantly cherry-pick
commits from your development branches into master
/release branches, instead of using the usual merge
command, just in order to avoid overriding a settings file, you might want to consider having the production, deployed version of the settings file generated by some kind of script during deployment, and/or having separate settings files for your development and production environments, e.g. dev.settings
and production.settings
.
Alternatives to cherry-pick
You could also achieve the same effect of a cherry-pick
by using rebase --onto
or using patches, but using rebase --onto
can be more cumbersome to use if you're only trying to pick a single commit, and using patches takes more steps.
rebase
vs cherry-pick
to pick a single commit
As an example of how cumbersome rebase --onto
can be sometimes vs. cherry-pick
, say you have the following commits on a develop
branch:
develop
A <- B <- C <- D
Let's say you just want to merge C
into your master
branch. Using cherry-pick
, you simply use this (while on master
)
git cherry-pick C
To pick just a single commit with rebase --onto
however, you would need to go
git rebase --onto master B C
With the above, you're saying that you want to use the current position of master
as the new base commit/parent for C
, and B
is the old base/parent.
rebase
vs cherry-pick
to pick a range of commits
Picking a range of commits becomes very similar between the two commands though. For example, say you want to merge both B
and C
. Then
git cherry-pick A..C
git rebase --onto master A C
are equivalent, though the cherry-pick
needs to be done while master
is checked out, but rebase --onto
does not, because it will check out master
for you.
Using patches
If you want to see how much more work it would be to use patches, you can read about using them in the Pro Git book.