The way a cherry-pick works is by taking the diff a changeset represents (the difference between the working tree at that point and the working tree of its parent), and applying it to your current branch.

So, if a commit has two or more parents, it also represents two or more diffs - which one should be applied?

You're trying to cherry pick fd9f578, which was a merge with two parents. So you need to tell the cherry-pick command which one against which the diff should be calculated, by using the -m option. For example, git cherry-pick -m 1 fd9f578 to use parent 1 as the base.

Parent 1 is the "first parent", 2 is the "second parent", and so on. The order is the one in which they're listed in the commit (as viewed by git show and the like).

I can't say for sure for your particular situation, but using git merge instead of git cherry-pick is generally advisable. When you cherry-pick a merge commit, it collapses all the changes made in the parent you didn't specify to -m into that one commit. You lose all their history, and glom together all their diffs. Your call.

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.

Lets assume you have something like this:

X - master
|
|
M
|\
| \
X  B - merged_feature_branch
|  |
|  |
X  A    X - cherry_pick_destination
| /     |
|/      |
X       X
|      /
|     /

Now you have two choices:

• cherry pick only A and B
• cherry pick M against first parent (-m 1)

Both solution will introduce same change, but IMHO first approach is more readable. In case if some conflicts where resolved when committing M then second option may be preferred..