git/Bitbucket - 如何在不更改 HEAD 的情况下将新分支合并到 master 中？

Question

I'm trying to merge a newly created branch (from master branch) into master. However, when merging git HEAD points to master and also the newly merged branch and the master branch is identifiable by this newly created branch rather than just master by itself.

As an example:

• From master create new branch Feature_A
• Add and remove some files from Feature_A, also commit and push these changes to Feature_A
• Want to merge Feature_A with master

I took the steps of doing:

• git checkout master
• git merge Feature_A

However, in doing these steps HEAD points to -> (HEAD -> master, origin/master, origin/HEAD, origin/Feature_A, Feature_A).

Because of this it seems like this repo is now identifiable by Feature_A rather than master. So my question is how can I avoid this and rather merge the changes from Feature_A into master completely such that it doesn't point the HEAD to the merged branch?

(I'm also using Bitbucket, but CLI/VScode if this helps, and there is no "MERGE" badge after doing this).

Answer 1

I think you are in a situation like this before trying to merge:

* ffffff (HEAD, feature_a, origin/feature_a) Some more work on feature A
* eeeeee Some work on feature A
* dddddd (master, origin/master) Some previous work that was merged into master
* ...

I'm trying to describe here that you created a new branch from master and then committed some work on that branch. But the critical thing is that you didn't make any commits on master or merge other branches into master (which amounts to the same thing as makign commits on master as far as git is concerned).

In this case, when you do git checkout master and git merge feature_ , git will perform a so-called fast-forward merge. (Read the output after the merge to confirm this. It says exactly what it is doing.) This means that master simply moves to the same commit as feature_a , but no merge commit is created. If you want a merge request, there is a flag to do so when you do git merge . Check out the documentation for details.

Answer 2

A standard (non-fast-forward) git merge creates a merge commit, where the previous tips of both branches become the direct ancestors of the merge commit. This is the fundamental definition of a merge. That merge commit appears on the branch that was the target of the merge, and once you push that branch it also appears upstream.

Here's an example of a git commit graph for a merge I had laying around:

*   ff72a376 - (HEAD -> develop, origin/develop) Merge pull request #463 'issue469' into develop (2022-11-15 12:29:46 -0800) <bonachea>
|\  
| * 6cf6ccaa - (fork/issue469, issue469) ... (2022-11-15 12:29:23 -0800) <bonachea>
| * f40dc706 - ... (2022-11-15 12:29:23 -0800) <bonachea>
|/  
*   cecb516c - Merge pull request #462 into develop (2022-11-10 14:16:21 -0500) <bonachea>

This is right after a merge of my local branch issue469 (which tracks upstream fork/issue469 ) into develop (ie git checkout develop; git merge --no-ff issue469 ) and I've then pushed develop upstream to origin/develop ( git push origin develop ). Note the merge commit is a child of the tip of the issue469 branch, and the previous tip of develop ( cecb516c ). However the issue469 branch (local or upstream) does not contain the merge commit, unless I take further actions to make that happen. Ie:

$ git describe --always --exclude '*' HEAD
ff72a376
$ git describe --always --exclude '*' develop
ff72a376
$ git describe --always --exclude '*' origin/develop
ff72a376
$ git describe --always --exclude '*' issue469
6cf6ccaa
$ git describe --always --exclude '*' fork/issue469
6cf6ccaa

HEAD is a local marker that always tracks the current state of my working directory, which right now corresponds to the tip of develop == origin/develop , but as soon as I make more commits or checkout another branch it moves appropriately.