Does git merge add all commits or only last commit?

You can do the experiment by your self very easily (Require use of the terminal)

Go to your favorite folder in your command line:

Create an empty repo

mkdir test-repo
cd test-repo
git init

Add Some content (We will create a file that we will change the content every commit)

echo 0 > file.txt
git add file.txt
git commit -m '0'

Create branch A

git checkout -b A
echo 1 > file.txt; git add file.txt; git commit -m '1'
echo 2 > file.txt; git add file.txt; git commit -m '2'
echo 3 > file.txt; git add file.txt; git commit -m '3'
git log --graph --oneline --all

Create Branch B

git checkout master
git checkout -b B
echo 4 > file.txt; git add file.txt; git commit -m '4'
echo 5 > file.txt; git add file.txt; git commit -m '5'
git log --graph --oneline --all

So in Branch A we have a file with the number 3 and in B a file with the number 5 Lets merger A into B (your current branch is B, remember)

git merge B

You will see an easy conflict to solve

cat file.txt

<<<<<<< HEAD
5
=======
3
>>>>>>> A

Fixed and commit:

git commit
git log --graph --oneline --all

The history will look something like:

What happens here, You just create a new commit that links A int B, This commit has the conflict resolution between the 2 branches. And you still in the branch B

This implies you can remove this commit and come back to the preview state just removing this commit:

git reset --hard HEAD~1
git log

So now let's do the other way around, go to the branch A and lets 'merge B into A'.

git checkout A
git merge B

Fix the conflict again that looks pretty similar, but not exactly

cat file.txt


<<<<<<< HEAD
3
=======
5
>>>>>>> B

Fix the conflict and you should be in the same state but technically not :) You are in the branch B

git commit
git log --graph --oneline --all 

So what are the differences? the order of the conflict but the more important, the name of the final branch that you are in.

So merge create another commit to link the different history of a branch into another one (That's why the commit 0 does not repeat in this example) .

If you like a clean history, where the final history is something like :

You should play with rebase. But this looks outside the scope of this question.

If you want to create only a single commit from a branch to add into another branch you can squash and rebase

Git is something that is easier when you learn by doing. CHeck your git log often. Learn how to use git reflog to gain confidence (is the reason why git is great) and give a chance to git rebase commands. Then talk with your team and decide the best workflow.

1. commits are not "moved" into branch.
2. each commit in git stores link to parent commit.
3. merge commits have 2 or more parent commits(they are typically HEAD of appropriate branches)
4. since those commits still keep their parent commits merge operation virtually "brings all different commits(not existing in current branch before) into current branch". virtually means you will "remove" them from current branch once you remove merge commit(with git reset or git revert)

on the opposite:

a. making rebase would bring all "different" commits by copying them; they will "behave" just like native commits initially created for current branch

b. cherry-pick would make a copy just single commit(last one if you use branch name as an argument); but you can specify a range