Does git reset HEAD~ on master automatically merge a branch merge conflict-CodePudding

Does git reset HEAD~ on master automatically merge a branch merge conflict?

I had a branch A and tried to merge with MASTER. But there was a merge conflict. So I checkout to MASTER and run git reset HEAD~.

I ran git status on MASTER and found that branch A's latest commit got unstaged after reset on MASTER. So I ran git add . and commited to MASTER. It seems like branch A got merged with MASTER. Everything works like how I want it to but just curious if that's how reset works?

flow of what I ran..

on branch A

git add . 
git commit 
git checkout master

on MASTER

git merge A
warning: Cannot merge binary files: db.sqlite3 (HEAD vs. 
A)
Auto-merging db.sqlite3
CONFLICT (content): Merge conflict in db.sqlite3
Removing blog/templates/blog/comments_listview.html
Auto-merging blog/templates/blog/comments.html
Automatic merge failed; fix conflicts and then commit the result.

pushed branch A to github just in case

git reset HEAD~
Unstaged changes after reset:
M       blog/static/blog/base.js
M       blog/templates/blog/comments_listview.html
M       blog/templates/blog/comments.html
M       db.sqlite3


git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified:       blog/static/blog/base.js
modified:       blog/templates/blog/comments_listview.html
modified:       blog/templates/blog/comments.html
modified:       db.sqlite3

git add .
git commit

and now MASTER seems like it merged with branch A? I did have to stage the modified files and commit. The only conflict in the merge conflict with branch A was the file 'db.sqlite3'. And that didn't get 'merged' with MASTER.

CodePudding user response：

Does git reset HEAD~ on master automatically merge a branch merge conflict?

No.

It seems like branch A got merged with MASTER

It didn't.

CodePudding user response：

You may have accidently got the result you wanted by following the sequence you described, when branch A contains the addition of new files only: i.e. you did not update any files, or update files. If this is the case, it works accidently because the attempted merge would have brought the new files into your file system, and the git add . would have added it to the new commit you created.

So now you would see that the latest commit on master would comprise what was the latest commit in master before you reset it, with the addition of your new files. So from the end point of view, the correct files are in the repo, but the last commit was changed in order to achieve this state.