Where does git merge fit in this diagram

Question

I am learning git/github/version control and I found the diagram below really useful (source). My question is where does git merge fit into this diagram? Where would the arrow start and point to?

Answer 1

As I commented, "rebase" here is in the context of a git pull --rebase:

• fetch from the remote repository
• rebase on top of the remote tracking branch which just got updated by the fetch.

A git merge would be between local repository and workspace:

• local repository has the source of the merge: what you are merging from,
• workspace is your working tree, where you have checked out your current working branch: it is what you want to merge to.

You need a workspace in order to resolve possible merge conflicts.

While Schwern's answer is technically correct, it is confusing.

• yes, there are some edge cases (as seen here or there) where you could merge without involving a working tree.
• but a working tree is (almost always) involved when merging

The intent of the diagram is to show you where to look after a git command execution.

From "True Merge"

A merged version reconciling the changes from all branches to be merged is committed, and your HEAD, index, and working tree are updated to it.
It is possible to have modifications in the working tree as long as they do not overlap; the update will preserve them.

If you were to do a git merge in a bare repository (no working tree), you would get:

fatal: this operation must be run in a work tree

(From setup.c#setup_work_tree())

See also:

• "Git Merge (a Visual reference)"
• "Making Sense of Git – A Visual Perspective"

^{(Source: www.patrickzahnd.ch)}

For a more interactive visual Git cheatsheet: an interaction from NDP Software, from Andrew Peterson:

---

Don't forget that with Git 2.23 (released yesterday), you have two new (experimental) commands: git switch and git restore.
They could clarify what git checkout was doing before.

Answer 2

git merge is between two commits in your local repository to make a new commit; this cannot be expressed in the diagram. That new commit is then checked out into your working tree. If there's a conflict that is also checked out into your working tree for you to fix and commit.

The important distinction that might be lost in this diagram is the content of your workspace is not involved in the merge. git merge master is between the commit pointed at by master and the commit pointed at by HEAD (your currently checked out commit). The files in your workspace are not involved.

A more complete diagram of how changes flow would look like this.

| commit -a (add + commit) =======================> |
| add/rm =================> | commit =============> |
|                           | <==== reset -- <path> |
|                           |                       | push =======> |
|                           |                       |               |
workspace                   index                   local           remote
|                           |                       |               |
| <=========================================== pull (fetch + merge) |
|                                                   | <====== fetch |
| <========================================= rebase |
| <========================================== merge |
| <================================= checkout <rev> |
| <===== checkout -- <path> |
| <======================= checkout <rev> -- <path> |
| ========== diff ========= |
|                           | === diff --staged === |
| ============== diff <rev> ======================= |

Notes

• <rev> is a revision like a commit id, branch name, or tag.
• The "index" is better named the "staging area", it's where you build up (stage) a commit.
• Both add and rm write to the staging area.
• Because some Git commands take both a revision and a path, -- says what follows is unambiguously a path.
• git reset -- <path> can be thought of as "unstage".
• git diff shows what is changed but not staged.
• git diff --staged shows what you're about to commit.
• A pull is a fetch and then a merge (or rebase with git pull --rebase).
• Git doesn't speak to the remote unless you tell it to.
• checkout is a mess. The latest version of Git splits it into switch and restore.

Answer 3

I think that there is an error in the diagram and it's pull or pull --rebase that should be written.

rebase or merge,if that make sense to be displayed in this diagram (I don't think it helps to do it) , that would be between 'local repository' and 'workspace'.

Because you merge or rebase references (remote or local) that are already present in your local repository. And the updated reference/branch is the currently checked out one, so that update also the 'workspace'.

I hope it helps a little but don't give it too much importance because I'm not sure it will helps you to understand how the merge command works.