-<p>(or any other branch-name, for that matter) and if you forget which\r
-branch you happen to be on, a simple</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ ls -l .git/HEAD</tt></pre>\r
-</div></div>\r
-<p>will tell you where it's pointing (Note that on platforms with bad or no\r
-symlink support, you have to execute</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ cat .git/HEAD</tt></pre>\r
-</div></div>\r
-<p>instead). To get the list of branches you have, you can say</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git branch</tt></pre>\r
-</div></div>\r
-<p>which is nothing more than a simple script around <tt>ls .git/refs/heads</tt>.\r
-There will be asterisk in front of the branch you are currently on.</p>\r
-<p>Sometimes you may wish to create a new branch _without_ actually\r
-checking it out and switching to it. If so, just use the command</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git branch <branchname> [startingpoint]</tt></pre>\r
-</div></div>\r
-<p>which will simply _create_ the branch, but will not do anything further.\r
-You can then later — once you decide that you want to actually develop\r
-on that branch — switch to that branch with a regular <tt>git checkout</tt>\r
-with the branchname as the argument.</p>\r
-</div>\r
-<h2>Merging two branches</h2>\r
-<div class="sectionbody">\r
-<p>One of the ideas of having a branch is that you do some (possibly\r
-experimental) work in it, and eventually merge it back to the main\r
-branch. So assuming you created the above <tt>mybranch</tt> that started out\r
-being the same as the original <tt>master</tt> branch, let's make sure we're in\r
-that branch, and do some work there.</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git checkout mybranch\r
-$ echo "Work, work, work" >>hello\r
-$ git commit -m 'Some work.' hello</tt></pre>\r
-</div></div>\r
-<p>Here, we just added another line to <tt>hello</tt>, and we used a shorthand for\r
-doing both <tt>git-update-index hello</tt> and <tt>git commit</tt> by just giving the\r
-filename directly to <tt>git commit</tt>. The <tt>-m</tt> flag is to give the\r
-commit log message from the command line.</p>\r
-<p>Now, to make it a bit more interesting, let's assume that somebody else\r
-does some work in the original branch, and simulate that by going back\r
-to the master branch, and editing the same file differently there:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git checkout master</tt></pre>\r
-</div></div>\r
-<p>Here, take a moment to look at the contents of <tt>hello</tt>, and notice how they\r
-don't contain the work we just did in <tt>mybranch</tt> — because that work\r
-hasn't happened in the <tt>master</tt> branch at all. Then do</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ echo "Play, play, play" >>hello\r
-$ echo "Lots of fun" >>example\r
-$ git commit -m 'Some fun.' hello example</tt></pre>\r
-</div></div>\r
-<p>since the master branch is obviously in a much better mood.</p>\r
-<p>Now, you've got two branches, and you decide that you want to merge the\r
-work done. Before we do that, let's introduce a cool graphical tool that\r
-helps you view what's going on:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ gitk --all</tt></pre>\r
-</div></div>\r
-<p>will show you graphically both of your branches (that's what the <tt>--all</tt>\r
-means: normally it will just show you your current <tt>HEAD</tt>) and their\r
-histories. You can also see exactly how they came to be from a common\r
-source.</p>\r
-<p>Anyway, let's exit <tt>gitk</tt> (<tt>^Q</tt> or the File menu), and decide that we want\r
-to merge the work we did on the <tt>mybranch</tt> branch into the <tt>master</tt>\r
-branch (which is currently our <tt>HEAD</tt> too). To do that, there's a nice\r
-script called <tt>git merge</tt>, which wants to know which branches you want\r
-to resolve and what the merge is all about:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git merge "Merge work in mybranch" HEAD mybranch</tt></pre>\r
-</div></div>\r
-<p>where the first argument is going to be used as the commit message if\r
-the merge can be resolved automatically.</p>\r
-<p>Now, in this case we've intentionally created a situation where the\r
-merge will need to be fixed up by hand, though, so git will do as much\r
-of it as it can automatically (which in this case is just merge the <tt>example</tt>\r
-file, which had no differences in the <tt>mybranch</tt> branch), and say:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt> Trying really trivial in-index merge...\r
- fatal: Merge requires file-level merging\r
- Nope.\r
- ...\r
- Auto-merging hello\r
- CONFLICT (content): Merge conflict in hello\r
- Automatic merge failed/prevented; fix up by hand</tt></pre>\r
-</div></div>\r
-<p>which is way too verbose, but it basically tells you that it failed the\r
-really trivial merge ("Simple merge") and did an "Automatic merge"\r
-instead, but that too failed due to conflicts in <tt>hello</tt>.</p>\r
-<p>Not to worry. It left the (trivial) conflict in <tt>hello</tt> in the same form you\r
-should already be well used to if you've ever used CVS, so let's just\r
-open <tt>hello</tt> in our editor (whatever that may be), and fix it up somehow.\r
-I'd suggest just making it so that <tt>hello</tt> contains all four lines:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>Hello World\r
-It's a new day for git\r
-Play, play, play\r
-Work, work, work</tt></pre>\r
-</div></div>\r
-<p>and once you're happy with your manual merge, just do a</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git commit hello</tt></pre>\r
-</div></div>\r
-<p>which will very loudly warn you that you're now committing a merge\r
-(which is correct, so never mind), and you can write a small merge\r
-message about your adventures in git-merge-land.</p>\r
-<p>After you're done, start up <tt>gitk --all</tt> to see graphically what the\r
-history looks like. Notice that <tt>mybranch</tt> still exists, and you can\r
-switch to it, and continue to work with it if you want to. The\r
-<tt>mybranch</tt> branch will not contain the merge, but next time you merge it\r
-from the <tt>master</tt> branch, git will know how you merged it, so you'll not\r
-have to do _that_ merge again.</p>\r
-<p>Another useful tool, especially if you do not always work in X-Window\r
-environment, is <tt>git show-branch</tt>.</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git show-branch master mybranch\r
-* [master] Merge work in mybranch\r
- ! [mybranch] Some work.\r
---\r
-+ [master] Merge work in mybranch\r
-++ [mybranch] Some work.</tt></pre>\r
-</div></div>\r
-<p>The first two lines indicate that it is showing the two branches\r
-and the first line of the commit log message from their\r
-top-of-the-tree commits, you are currently on <tt>master</tt> branch\r
-(notice the asterisk <tt>*</tt> character), and the first column for\r
-the later output lines is used to show commits contained in the\r
-<tt>master</tt> branch, and the second column for the <tt>mybranch</tt>\r
-branch. Three commits are shown along with their log messages.\r
-All of them have plus <tt>+</tt> characters in the first column, which\r
-means they are now part of the <tt>master</tt> branch. Only the "Some\r
-work" commit has the plus <tt>+</tt> character in the second column,\r
-because <tt>mybranch</tt> has not been merged to incorporate these\r
-commits from the master branch. The string inside brackets\r
-before the commit log message is a short name you can use to\r
-name the commit. In the above example, <em>master</em> and <em>mybranch</em>\r
-are branch heads. <em>master~1</em> is the first parent of <em>master</em>\r
-branch head. Please see <em>git-rev-parse</em> documentation if you\r
-see more complex cases.</p>\r
-<p>Now, let's pretend you are the one who did all the work in\r
-<tt>mybranch</tt>, and the fruit of your hard work has finally been merged\r
-to the <tt>master</tt> branch. Let's go back to <tt>mybranch</tt>, and run\r
-resolve to get the "upstream changes" back to your branch.</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git checkout mybranch\r
-$ git merge "Merge upstream changes." HEAD master</tt></pre>\r
-</div></div>\r
-<p>This outputs something like this (the actual commit object names\r
-would be different)</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>Updating from ae3a2da... to a80b4aa....\r
- example | 1 +\r
- hello | 1 +\r
- 2 files changed, 2 insertions(+), 0 deletions(-)</tt></pre>\r
-</div></div>\r
-<p>Because your branch did not contain anything more than what are\r
-already merged into the <tt>master</tt> branch, the resolve operation did\r
-not actually do a merge. Instead, it just updated the top of\r
-the tree of your branch to that of the <tt>master</tt> branch. This is\r
-often called <em>fast forward</em> merge.</p>\r
-<p>You can run <tt>gitk --all</tt> again to see how the commit ancestry\r
-looks like, or run <tt>show-branch</tt>, which tells you this.</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git show-branch master mybranch\r
-! [master] Merge work in mybranch\r
- * [mybranch] Merge work in mybranch\r
---\r
-++ [master] Merge work in mybranch</tt></pre>\r
-</div></div>\r
-</div>\r
-<h2>Merging external work</h2>\r
-<div class="sectionbody">\r
-<p>It's usually much more common that you merge with somebody else than\r
-merging with your own branches, so it's worth pointing out that git\r
-makes that very easy too, and in fact, it's not that different from\r
-doing a <tt>git merge</tt>. In fact, a remote merge ends up being nothing\r
-more than "fetch the work from a remote repository into a temporary tag"\r
-followed by a <tt>git merge</tt>.</p>\r
-<p>Fetching from a remote repository is done by, unsurprisingly,\r
-<tt>git fetch</tt>:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git fetch <remote-repository></tt></pre>\r
-</div></div>\r
-<p>One of the following transports can be used to name the\r
-repository to download from:</p>\r
-<dl>\r
-<dt>\r
-Rsync\r
-</dt>\r
-<dd>\r
-<p>\r
- <tt>rsync://remote.machine/path/to/repo.git/</tt>\r
-</p>\r
-<p>Rsync transport is usable for both uploading and downloading,\r
-but is completely unaware of what git does, and can produce\r
-unexpected results when you download from the public repository\r
-while the repository owner is uploading into it via <tt>rsync</tt>\r
-transport. Most notably, it could update the files under\r
-<tt>refs/</tt> which holds the object name of the topmost commits\r
-before uploading the files in <tt>objects/</tt> — the downloader would\r
-obtain head commit object name while that object itself is still\r
-not available in the repository. For this reason, it is\r
-considered deprecated.</p>\r
-</dd>\r
-<dt>\r
-SSH\r
-</dt>\r
-<dd>\r
-<p>\r
- <tt>remote.machine:/path/to/repo.git/</tt> or\r
-</p>\r
-<p><tt>ssh://remote.machine/path/to/repo.git/</tt></p>\r
-<p>This transport can be used for both uploading and downloading,\r
-and requires you to have a log-in privilege over <tt>ssh</tt> to the\r
-remote machine. It finds out the set of objects the other side\r
-lacks by exchanging the head commits both ends have and\r
-transfers (close to) minimum set of objects. It is by far the\r
-most efficient way to exchange git objects between repositories.</p>\r
-</dd>\r
-<dt>\r
-Local directory\r
-</dt>\r
-<dd>\r
-<p>\r
- <tt>/path/to/repo.git/</tt>\r
-</p>\r
-<p>This transport is the same as SSH transport but uses <tt>sh</tt> to run\r
-both ends on the local machine instead of running other end on\r
-the remote machine via <tt>ssh</tt>.</p>\r
-</dd>\r
-<dt>\r
-git Native\r
-</dt>\r
-<dd>\r
-<p>\r
- <tt>git://remote.machine/path/to/repo.git/</tt>\r
-</p>\r
-<p>This transport was designed for anonymous downloading. Like SSH\r
-transport, it finds out the set of objects the downstream side\r
-lacks and transfers (close to) minimum set of objects.</p>\r
-</dd>\r
-<dt>\r
-HTTP(S)\r
-</dt>\r
-<dd>\r
-<p>\r
- <tt>http://remote.machine/path/to/repo.git/</tt>\r
-</p>\r
-<p>Downloader from http and https URL\r
-first obtains the topmost commit object name from the remote site\r
-by looking at the specified refname under <tt>repo.git/refs/</tt> directory,\r
-and then tries to obtain the\r
-commit object by downloading from <tt>repo.git/objects/xx/xxx...</tt>\r
-using the object name of that commit object. Then it reads the\r
-commit object to find out its parent commits and the associate\r
-tree object; it repeats this process until it gets all the\r
-necessary objects. Because of this behaviour, they are\r
-sometimes also called <em>commit walkers</em>.</p>\r
-<p>The <em>commit walkers</em> are sometimes also called <em>dumb\r
-transports</em>, because they do not require any git aware smart\r
-server like git Native transport does. Any stock HTTP server\r
-that does not even support directory index would suffice. But\r
-you must prepare your repository with <tt>git-update-server-info</tt>\r
-to help dumb transport downloaders.</p>\r
-<p>There are (confusingly enough) <tt>git-ssh-fetch</tt> and <tt>git-ssh-upload</tt>\r
-programs, which are <em>commit walkers</em>; they outlived their\r
-usefulness when git Native and SSH transports were introduced,\r
-and not used by <tt>git pull</tt> or <tt>git push</tt> scripts.</p>\r
-</dd>\r
-</dl>\r
-<p>Once you fetch from the remote repository, you <tt>resolve</tt> that\r
-with your current branch.</p>\r
-<p>However — it's such a common thing to <tt>fetch</tt> and then\r
-immediately <tt>resolve</tt>, that it's called <tt>git pull</tt>, and you can\r
-simply do</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git pull <remote-repository></tt></pre>\r
-</div></div>\r
-<p>and optionally give a branch-name for the remote end as a second\r
-argument.</p>\r
-<div class="admonitionblock">\r
-<table><tr>\r
-<td class="icon">\r
-<div class="title">Note</div>\r
-</td>\r
-<td class="content">You could do without using any branches at all, by\r
-keeping as many local repositories as you would like to have\r
-branches, and merging between them with <tt>git pull</tt>, just like\r
-you merge between branches. The advantage of this approach is\r
-that it lets you keep set of files for each <tt>branch</tt> checked\r
-out and you may find it easier to switch back and forth if you\r
-juggle multiple lines of development simultaneously. Of\r
-course, you will pay the price of more disk usage to hold\r
-multiple working trees, but disk space is cheap these days.</td>\r
-</tr></table>\r
-</div>\r
-<div class="admonitionblock">\r
-<table><tr>\r
-<td class="icon">\r
-<div class="title">Note</div>\r
-</td>\r
-<td class="content">You could even pull from your own repository by\r
-giving <em>.</em> as <remote-repository> parameter to <tt>git pull</tt>. This\r
-is useful when you want to merge a local branch (or more, if you\r
-are making an Octopus) into the current branch.</td>\r
-</tr></table>\r
-</div>\r
-<p>It is likely that you will be pulling from the same remote\r
-repository from time to time. As a short hand, you can store\r
-the remote repository URL in a file under .git/remotes/\r
-directory, like this:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ mkdir -p .git/remotes/\r
-$ cat >.git/remotes/linus <<\EOF\r
-URL: http://www.kernel.org/pub/scm/git/git.git/\r
-EOF</tt></pre>\r
-</div></div>\r
-<p>and use the filename to <tt>git pull</tt> instead of the full URL.\r
-The URL specified in such file can even be a prefix\r
-of a full URL, like this:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ cat >.git/remotes/jgarzik <<\EOF\r
-URL: http://www.kernel.org/pub/scm/linux/git/jgarzik/\r
-EOF</tt></pre>\r
-</div></div>\r
-<p>Examples.</p>\r
-<ol>\r
-<li>\r
-<p>\r
-<tt>git pull linus</tt>\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-<tt>git pull linus tag v0.99.1</tt>\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-<tt>git pull jgarzik/netdev-2.6.git/ e100</tt>\r
-</p>\r
-</li>\r
-</ol>\r
-<p>the above are equivalent to:</p>\r
-<ol>\r
-<li>\r
-<p>\r
-<tt>git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD</tt>\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-<tt>git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1</tt>\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-<tt>git pull http://www.kernel.org/pub/…/jgarzik/netdev-2.6.git e100</tt>\r
-</p>\r
-</li>\r
-</ol>\r