creating branch just for merge

Question

*this is one of those "is this a good idea?" questions that I can't really format into a SO acceptable question but....

I'm still not 100% comfortable with git, specifically merging with remote branches. If things go wrong or I just want to give up on a bunch of merge conflicts, I'm usually struggling to roll back merges/commits. I find myself farther down the rabbit hole so to speak. I'm wondering, would it be easier to create a branch just to do the remote merge on and then locally merge the temp branch with my "real" branch"? This way I could always nuke the temp branch if something went wrong.

UPDATE: I'm specifically interested in when my remote branch will add a bunch of files to my repo. For example (using Peter's example below):

I do this:

$ git init
Initialized empty Git repository in /path/to/repo/.git/
$ touch README
$ git add README
$ git commit -m 'Initial commit'
[master (root-commit) da9886d] Initial commit
 0 files changed
 create mode 100644 README
$ touch A
$ git add A
$ git commit -m 'Add A'
[master 3480a5b] Add A
 0 files changed
 create mode 100644 A
$ git push // pushed to remote (only a single file, A)

Then another developer does this:

$ git clone
$ touch B
$ git add B
$ git commit -m 'Add B'
[foo 9912a23] Add B
 0 files changed
 create mode 100644 B
$ git push // pushed to remote (now has two files A and B)

If I then do this:

$ git pull

I'll have two files A and B. Now If I want to "step back" and undo the merge:

$ git reset --hard master@{...}

File B will still exist on my machine as an untracked file, right? How can I step back and remove these files as if I NEVER did the git merge?

This is why I was hoping to create a separate branch. If I create a separate branch to do the merge:

$ git checkout -b tempBranchForMerge
$ git pull

I still end up with files A and B but they exist only on tempBranchForMerge. If things go wrong, I should be able to do this:

$ git checkout master
$ git branch -d tempBranchForMerge

right? This will delete file B.

Answer 1

That's absolutely fine, but unnecessary.

Git already tracks a history of where your branches move which you can access with git reflog. I particularly like git reflog <branch name>.

Let's try an example. Here's a bunch of commands just setting up this example. I've got a master and a foo branch. Each has one commit. Then I merge foo into master.

$ git init
Initialized empty Git repository in /path/to/repo/.git/
$ touch README
$ git add README
$ git commit -m 'Initial commit'
[master (root-commit) da9886d] Initial commit
 0 files changed
 create mode 100644 README
$ touch A
$ git add A
$ git commit -m 'Add A'
[master 3480a5b] Add A
 0 files changed
 create mode 100644 A
$ git checkout -b foo HEAD~1
Switched to a new branch 'foo'
$ touch B
$ git add B
$ git commit -m 'Add B'
[foo 9912a23] Add B
 0 files changed
 create mode 100644 B
$ git log --decorate --graph --all --pretty=oneline --abbrev-commit
* 9912a23 (HEAD, foo) Add B
| * 3480a5b (master) Add A
|/
* da9886d Initial commit
$ git checkout master
Switched to branch 'master'
$ git merge foo
Merge made by the 'recursive' strategy.
 0 files changed
 create mode 100644 B
$ git log --decorate --graph --all --pretty=oneline --abbrev-commit
*   d4d06ce (HEAD, master) Merge branch 'foo'
|\
| * 9912a23 (foo) Add B
* | 3480a5b Add A
|/
* da9886d Initial commit

Now let's suppose I wanted to undo that merge commit, that is put master back to whatever it was before the commit.

$ git reflog master
d4d06ce master@{0}: merge foo: Merge made by the 'recursive' strategy.
3480a5b master@{1}: commit: Add A
da9886d master@{2}: commit (initial): Initial commit
$ git reset --hard master@{1}
HEAD is now at 3480a5b Add A
$ git log --decorate --graph --all --pretty=oneline --abbrev-commit
* 9912a23 (foo) Add B
| * 3480a5b (HEAD, master) Add A
|/
* da9886d Initial commit