2

What are the pros and cons of using cherry-pick versus merge for release management?

Background

We have a dev branch, and just created a release1 branch from it. Folks will commit relevant content to release1, and we'll need that content in dev for the next releases. The obvious solution (to me) is to git merge release1 to dev occasionally (completing the merge PRs with merge, not squash!).

However, most devs are used to cherry-picking their changes from release1 to dev. I tried to argue that using git merge will:

  • Keep track of which commits are merged, thus preventing us from forgetting commits in release1
  • Merge changes correctly, reducing merge conflicts, although I don't have a concrete example how that would happen.

One downside: If there's content that goes to release1 but doesn't need to go to dev - for example some temporary mock data - then we can just not cherry-pick it, while we can't skip it in merge.

Improve this question
9
  • 2
    see How do I explain ${something} to ${someone}? Commented Nov 5, 2024 at 10:22
  • 2
    Has your team given reasons why they use cherry-pick by default? Commented Nov 5, 2024 at 10:56
  • @PhilipKendall: The whole project has many long-term branches that do need cherry-picking between. So they're used to that and consider the resulting management overhead as inevitable. Also, there's a policy that PRs can't be merged, only squashed, though I can get that changed. Commented Nov 5, 2024 at 11:01
  • Before convincing devs to merge branches as a whole, you need to train them to put every commit into the branch (or maybe all branches) where they belong to. Commented Nov 5, 2024 at 15:37
  • @DocBrown: They already know where to commit. The problem is the back-merge. Commented Nov 6, 2024 at 8:52

2 Answers 2

Reset to default
2

Merging provides a clearer and more complete picture of the changes leading up to each feature release or bug fix, making it easier for developers to trace back and understand why certain decisions were made. Cherry-picking can create fragmented or isolated commits, which makes tracking the development history and debugging more complex. It also increases the risk of human error, such as accidentally omitting commits, including those that other changes depend on. In practical terms, if you cherry-pick only some commits from a sequence with dependencies, you might end up with code that fails to compile, causes bugs, or doesn’t reflect the intended feature because the cherry-picked commits lack the full context. Merging, on the other hand, preserves the order and structure of dependent commits, reducing these risks.

If you are not using CI at the moment, and if you decide to go that way in future, merging is more CI-friendly. In my experience, CI tools (Jenkins springs to mind) handle branch merges much better than workflows that rely on individual cherry-picked commits, which are applied one-by-one to the target branch. Proper merging creates more stable integration points and enables smoother automation, both of which support reliable testing and deployment.

Merging is widely adopted as a best practice because it preserves commit history and dependencies, supporting a stable and predictable workflow. This also simplifies onboarding, as new team members are likely familiar with standard git workflows.

Finally, depending on how your company handles releases, merging provides the QA team with a consistent and complete set of changes. This makes test planning and execution more straightforward, reducing the risk of missing dependencies or introducing regressions. Unlike cherry-picking, merging allows QA to validate cohesive features or fixes in one go, minimising repeated testing and simplifying communication around what is included in each build. Additionally, merging enhances CI integration, making automated tests more reliable and reducing manual checks, so QA can focus on thorough testing rather than troubleshooting incomplete changes.

Improve this answer
1
  • TLDR: never-ever cherry-pick or rebase in public. Commented Dec 15, 2024 at 10:51
0

Some details about the git flow the team uses could help getting answers closer to what you are looking for than How do I explain ${something} to ${someone}? that has been mentioned in comments.

From description it seems there are several branches constantly out of sync, the team is uncertain about what branch the code in production has been released. dev branch is behind the release branch while it should be the other way around, the dev branch it should be ahead of production code and that's why the team finds git cherry-pick more convenient than merge. Is the dev a development slow down? 'cause this is what it seems to happen. I would say a redesign of the git flow the team follows would shed a different light over the git commands the team members use.

Improve this answer
1
  • If release branches are merged into dev it would be up-to-date instantly, so it failing behind is not a concern. Commented Nov 5, 2024 at 17:41

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.