GitLab GUI合并分支异常咨询：从development分支合并至长期特性分支时出现非预期双向合并

Background #

You're working with two branches: the default development branch and a long-lived feature branch 5-feature-branch. Your goal was to merge development into 5-feature-branch to update the feature branch, using GitLab's GUI with these settings:

• Simple merge
• Enable no-ff option
• Squash commits enabled

Expected Outcomes #

• development branch remains completely unchanged, with its commit history intact
• 5-feature-branch gets a new merge commit that clearly records the merge from development

Actual Results #

1. 5-feature-branch was merged into development first
2. Then development was merged back into 5-feature-branch
3. Running git diff development..5-feature-branch shows no differences between the two branches

Is This a GitLab Bug? #

This is almost certainly not an unupdated GitLab bug—it's far more likely a mix-up in how you selected branches in the GitLab GUI, or confusion with the platform's merge request (MR) logic.

What Happened #

GitLab's merge request workflow is centered around merging a source branch into a target branch. If you accidentally set 5-feature-branch as the source and development as the target when creating your MR, GitLab would merge the feature branch into your default branch first. If you then tried to "fix" this by creating another MR to merge development back into 5-feature-branch, you'd end up with the bidirectional merge history you're seeing.

The squash commits option amplifies this confusion: GitLab compresses all source branch commits into a single commit before merging, which makes the reverse merge look like it's syncing changes back, even though the end result is identical branches.

Why the Command Line Worked #

Your command line approach was correct and aligned with your expectations:

$ git checkout 5-feature-branch
$ git merge --no-ff development
# Fix conflicts
$ git commit

By checking out the feature branch first and merging development into it directly, you're only modifying the feature branch's history—development stays untouched, exactly what you wanted.

Fixes & Recommendations #

• Double-check branch selection in GitLab: When creating a merge request, confirm that development is set as the source branch and 5-feature-branch is the target branch before proceeding.
• Undo the accidental merge (if safe): If no one else has pulled the merged development branch, you can reset it to its pre-merge state with:

  $ git checkout development
  $ git reset --hard <pre-merge-commit-hash>
  

  Note: This will discard all changes from the accidental merge—only do this if you're sure it's safe.
• Stick to command line for this workflow: For updating long-lived feature branches, the command line gives you direct control over which branch you're merging into, avoiding GUI-related mix-ups.

内容的提问来源于stack exchange，提问作者KrNeki