Cherry Picking vs. Merging and Avoiding Double Merges

This guide clarifies cherry-picking, avoiding double merges, and best practices for integrating changes between branches in Git. We'll address common concerns and provide recommendations for different branch interaction scenarios.

Cherry-Picking

Cherry-picking allows you to selectively copy individual commits from one branch and apply them to another. While powerful, it can create a messy history if misused. Here's when it can be useful and when to avoid it:

Good Use Cases:

• Applying a small bug fix: If a critical bug fix resides in a feature branch (child branch) that you need in another feature branch or even the master branch before the feature is complete, cherry-picking the bug fix commit can be a good option. This allows you to apply the fix without having to merge the entire feature branch prematurely.

• Picking specific commits from an abandoned branch: If a branch has some useful commits but also unwanted ones, you can cherry-pick the desired commits to a new branch. This allows you to salvage useful work from a branch that may otherwise be discarded.

When to Avoid Cherry-Picking:

• Large or complex changes: Cherry-picking large or complex changes can lead to merge conflicts if the target branch has diverged significantly since the commit was made. In such cases, a proper merge (explained later) is recommended. This is because a merge takes into account the entire history of changes, reducing the likelihood of conflicts.

• Maintaining a clean history: Frequent cherry-picking can make the commit history convoluted and harder to understand. If multiple branches share a lot of history, consider using merges instead to keep the history linear. This makes it easier to understand the evolution of the project over time.

Double Merging (Avoid This)

Making the same commit to multiple child branches that will eventually be merged into the master branch is generally bad practice. Here's why:

• Redundant Work: It creates unnecessary duplication in your commit history. Each commit should ideally represent a unique change. Having the same change represented in multiple commits can confuse developers and make the history harder to understand.

• Merge Conflicts: If the same changes are made independently in multiple branches, merging them into the master branch can lead to conflicts that need to be resolved manually. This can be time-consuming and error-prone.

Recommended Approach - Merging Branches

In most cases, merging branches is the preferred approach for integrating changes. Merging combines the entire history of two branches, creating a new commit at the merge point.

Here's a breakdown of common scenarios and the recommended approach:

Explore GitHub Features

GitHub offers a variety of features that can enhance your workflow and productivity. Here are some of them:

Branch Protection

Branch protection rules prevent team members from making changes to important branches. Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server.

With protected branches, you can:

• Disable force pushing (prevents history from being erased)
• Require pull request reviews before merging (ensures code is reviewed)
• Require status checks to pass before merging (ensures all tests are passing)
• Enforce restrictions on who can push to the branch (control who can make changes)

Learn more about Branch Protection

Merge Queues

Merge queues are currently in beta and available for repositories owned by organizations using GitHub Team or GitHub Enterprise Cloud. With merge queues, you can control the order of merging for pull requests targeting the same branch. This can help to avoid "merge hell" where multiple PRs are trying to merge at the same time and causing conflicts.

Learn more about Merge Queues

Code Owners

With the code owners feature, you can define individuals or teams that are responsible for code in a repository. Code owners are automatically requested for review when someone opens a pull request that modifies code that they own.

Learn more about Code Owners

Merge Decision Flowchart

Note: This chart starts with the same decision process for whether to use cherry-pick or merge. After that, it checks if there are branch protection rules. If there are, it checks if status checks have passed. If they have, it checks if a merge queue is being used. If it is, the merge is done via the queue. If not, the merge is done directly. If status checks have not passed, the merge cannot be done. If there are no branch protection rules, the merge is done directly.

graph TD;
    A[Start] --> B{Is it a small bug fix?};
    B -->|Yes| C[Cherry-pick the commit];
    B -->|No| D{Is it a large or complex change?};
    D -->|Yes| E[Merge the branches];
    D -->|No| F[Consider cherry-pick or merge];
    E -->|Branch Protection Rule?| G{Status Checks Passed?};
    G -->|Yes| H{High Traffic Repo?};
    H -->|Yes| I{Merge Queue?};
    I -->|Yes| J[Merge via Queue];
    I -->|No| K[Consider Using Merge Queue];
    H -->|No| L[Merge Directly];
    G -->|No| M[Cannot Merge];
    E -->|No Branch Protection Rule| L;
    F --> G;
    C --> G;
    J --> N[End];
    K --> N;
    L --> N;
    M --> N;