I've just been promoted to a junior developer role and now I'm tasked with reviewing code and merging pull requests from my team. We started using the 'cherry-pick' command in git to selectively bring over code snippets. However, I've noticed that depending on how I use it, it seems to create new commits that can overwrite the original ones, making it tough to trace who originally wrote the code. I'm looking for tips to better understand cherry-pick and avoid these issues. If there are alternative git tools that allow me to take snippets for a release branch without losing the original context, I'd love to hear about those too!
2 Answers
It's a common misconception that `git cherry-pick` overwrites commits. It actually creates a new commit with the same changes as the one you're picking but on a different branch. The original commit still retains its author information and timestamp, so you can trace back to who made the changes. If you use `git cherry-pick -x`, it even adds a note in the commit message indicating where it came from. Just keep in mind that `cherry-picking` is not as good as merging for maintaining history. If you want to keep a detailed track of commits, consider using `git merge` instead. Try using cherry-pick to refine feature branches and then merge them back when they're ready instead.
I've mainly used `cherry-pick` for assembling release branches when we can't branch directly from master. In a typical workflow, I'd recommend sticking to standard merges unless you're in a situation where cherry-picking is beneficial. This way, you'll maintain clearer history without mixing things up too much.
So, you only use cherry-pick in specific cases? That’s really helpful to know!
That makes a lot of sense! Thanks for clarifying that. I'll check out the `-x` option too.