Menu
I'm not a developer. On one of our projects, since a lot of tickets take time to complete, we have been cherry-picking our commits, and now we have to do it very often. I was told by a developer that cherry-picking should be avoided as it makes the repo unstable. What does that mean, how does it make the repo unstable? In other words, what are the negative consequences of cherry-picking?
997
Cherry picking has a negative connotation as the practice neglects, overlooks or directly suppresses evidence that could lead to a complete picture. Cherry picking can be found in many logical fallacies.
Cherry picking is the act of picking a commit from a branch and applying it to another. git cherry-pick can be useful for undoing changes. For example, say a commit is accidently made to the wrong branch. You can switch to the correct branch and cherry-pick the commit to where it should belong.
It is possible to cherry pick from another repo using the command line. You will first need to add the other repository as a remote and then fetch the changes. From there, you should be able to see the commit in your repo and cherry pick it.
Points to remember git cherry-pick <commit-hash> to cherry-pick a commit from another branch. git cherry-pick -n <commit-hash> to cherry-pick the commit but it won't commit the changes. It will only stage all the changes. git cherry-pick —continue or git cherry-pick —abort when you face conflicts while cherry-picking.
A typical use case for Git cherry-picking is bringing a commit from one branch into another branch, because the usual means of doing this, e.g. via a merge or rebase, are not available. The usual merge option might not be available because a feature branch is not yet ready to be merged to its source. However, a certain commit might be needed in the source branch immediately, e.g. for a bug or other hot fix, and so cherry-picking is one means to do this.
Cherry-picking does not really make the repository unstable, but what is does do it to run the risk of duplicating commits all over the place. Going back to the example of a feature branch having a commit which needs to go back to the source immediately, if we later do merge this feature branch, then we might be bringing in the same commit which was cherry-picked. As a result, the source branch could end up with multiple commits each of which functionally was supposed to do the same thing. This doesn't really make the repo unstable, but it does leave the history hard to read. In the future, readers of the history may find it difficult to figure out what the contributors were doing such that duplicated commits arose.
At the root of this problem is that Git cherry-pick actually creates a new commit, with a new SHA-1 hash, each time it is used. So, cherry-picking a single commit from a feature branch into the source actually leaves the repository with two commits, functionally identical, but with completely different SHA-1 hashes.
155
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
