要約

A developer cherry-picks code from a Feature Branch to the Main Branch and then later decides to restore the cherry-picked lines of code to their original values shortly before merging to Main. However, after the merge, it is observed that the revert to the original values does not get successfully applied Feature to the Main Branch.

環境

Tested on Bitbucket Data Center 8.19.1
Applies to Bitbucket Data Center 8.x

診断

• Verify if a git cherry-pick was executed from the source branch to the target branch before the merge.

• Examine whether the cherry-picked lines of code were modified in any subsequent commits in the source branch.

原因

Developers may frequently consider using git cherry picking to quickly incorporate fixes or configuration changes from a feature (or other) branch into the main branch. While cherry-picking can be beneficial in specific scenarios, it's crucial to exercise extreme caution when using it. If not carefully managed, cherry-picking can cause unintended problems down the line.

In this article, we'll explore one such problem that arises when a cherry-picked changeset is reverted and then merged back into the main branch. Below is an overview of the sequence of events that can lead to this problem followed by an explanation into its cause:

• In this case study, we will trace the journey of a hypothetical configuration setting within a file, initially set to "Value = red" in our Main Branch.

• A Feature Branch is branched off from the Main Branch, and one or more feature commits are made (denoted as F1). At this stage, none of the commits modify the file in question.
  

• Subsequently, a problem is identified, compelling a developer to update the file to "Value = blue" and commit this change (F2) to the Feature Branch.

• This specific commit (F2) is then cherry-picked into the Main Branch to implement the temporary fix, updating the file in the Main Branch to "Value = blue" (M2).
  
    In the above Diagram the dashed arrow represent cherry picking. 

• Later, the developer devises a more effective solution to the problem, one that doesn't necessitate altering the "Value". Consequently, the developer reverts the file back to "Value = red" in the next commit (F3) on the Feature Branch.

• Upon merging the Feature Branch back into the Main Branch (M3), it's observed that the Main Branch retains "Value = blue", indicating that the reverted value "Value = red" has not been successfully promoted to the Main branch. Even worse, there is no merge conflict or any other indication that the reverted Value has not been promoted to Main.
  
    In the above Diagram the solid arrow represents merging.

In order understand this behaviour, we will break down the explanation into two key points.

1. Cherry-Picking and the Merge Base: Unlike a git merge, cherry-picking a commit does not alter the merge base, or the most recent common ancestor, between branches. This concept is important for understand the next explanation.

2. Determining the Merge Base and Merging: When merging, git identifies a "merge base," which is the most recent common ancestor of the branches involved. This merge base serves as a reference point for comparing the ends of the branches for any changes. In our scenario, the merge base is recognized as M1 (not M2, since M2's introduction was through cherry-picking). Examining the changes from M1 to F3, the file remains unchanged. However, from M1 to M3, the file has been updated to "Value = blue." Given this, since the Feature Branch shows no change from the merge base, while the Main Branch does, git concludes that the Main Branch's updated value "Value = blue" should be preserved and incorporated into the merge outcome.

ソリューション

• To address the issue, the only way to reapply the change to Main is by creating a new branch, implementing the desired modification, and then merging this branch to Main..
• The example outlined above is the expected behavior of git. Please make sure that your developers are aware of the potential complications that can arise from the use of git cherry-pick.
• Exercise caution with git cherry-picking, especially if there's uncertainty about whether the cherry-picked lines of code might be modified in the future and if the two branches will eventually merge. In scenarios where quick fixes or temporary changes are needed, it is advisable to adopt alternative strategies, such as creating a hotfix branch, to ensure a smoother integration process.