Fetching and Merging in Git

and transfers (close to) minimum set of objects. It is by far the most efficient way to exchange Git objects between repositories. Local directory:: `/path/to/repo.git/` + This transport is the same as SSH transport but uses 'sh' to run both ends on the local machine instead of running other end on the remote machine via 'ssh'. Git Native:: `git://remote.machine/path/to/repo.git/` + This transport was designed for anonymous downloading. Like SSH transport, it finds out the set of objects the downstream side lacks and transfers (close to) minimum set of objects. HTTP(S):: `http://remote.machine/path/to/repo.git/` + Downloader from http and https URL first obtains the topmost commit object name from the remote site by looking at the specified refname under `repo.git/refs/` directory, and then tries to obtain the commit object by downloading from `repo.git/objects/xx/xxx...` using the object name of that commit object. Then it reads the commit object to find out its parent commits and the associate tree object; it repeats this process until it gets all the necessary objects. Because of this behavior, they are sometimes also called 'commit walkers'. + The 'commit walkers' are sometimes also called 'dumb transports', because they do not require any Git aware smart server like Git Native transport does. Any stock HTTP server that does not even support directory index would suffice. But you must prepare your repository with 'git update-server-info' to help dumb transport downloaders. Once you fetch from the remote repository, you `merge` that with your current branch. However -- it's such a common thing to `fetch` and then immediately `merge`, that it's called `git pull`, and you can simply do ---------------- $ git pull <remote-repository> ---------------- and optionally give a branch-name for the remote end as a second argument. [NOTE] You could do without using any branches at all, by keeping as many local repositories as you would like to have branches, and merging between them with 'git pull', just like you merge between branches. The advantage of this approach is that it lets you keep a set of files for each `branch` checked out and you may find it easier to switch back and forth if you juggle multiple lines of development simultaneously. Of course, you will pay the price of more disk usage to hold multiple working trees, but disk space is cheap these days. It is likely that you will be pulling from the same remote repository from time to time. As a short hand, you can store the remote repository URL in the local repository's config file like this: ------------------------------------------------ $ git config remote.linus.url https://git.kernel.org/pub/scm/git/git.git/ ------------------------------------------------ and use the "linus" keyword with 'git pull' instead of the full URL. Examples. . `git pull linus` . `git pull linus tag v0.99.1` the above are equivalent to: . `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD` . `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1` How does the merge work? ------------------------ We said this tutorial shows what plumbing does to help you cope with the porcelain that isn't flushing, but we so far did not talk about how the merge really works. If you are following this tutorial the first time, I'd suggest to skip to "Publishing your work" section and come back here later. OK, still with me? To give us an example to look at, let's go back to the earlier repository with "hello" and "example" file, and bring ourselves back to the pre-merge state: ------------ $ git show-branch --more=2 master mybranch ! [master] Merge work in mybranch * [mybranch] Merge work in mybranch -- -- [master] Merge work in mybranch +* [master^2] Some work. +* [master^] Some fun. ------------ Remember, before running 'git merge', our `master` head was at "Some fun." commit, while our `mybranch` head was at "Some work." commit. ------------ $ git switch -C mybranch

This section discusses fetching changes from a remote repository using various transport methods, such as SSH, Local directory, Git Native, and HTTP(S), and then merging those changes into the current branch using 'git pull', which is a combination of 'git fetch' and 'git merge', and also explains how merge works in Git.