diff options
| author | Junio C Hamano <junio@hera.kernel.org> | 2008-05-26 01:16:14 +0000 |
|---|---|---|
| committer | Junio C Hamano <junio@hera.kernel.org> | 2008-05-26 01:16:14 +0000 |
| commit | dfccbb0719b88f4df05bf718c6008166dbadea44 (patch) | |
| tree | ddd5483c51044cab7a070039655f0b4074b1dfe6 /gittutorial.html | |
| parent | b713ff1cbf5b9979edaf2b85bfc568fbc37ec0d7 (diff) | |
| download | git-htmldocs-dfccbb0719b88f4df05bf718c6008166dbadea44.tar.gz | |
Autogenerated HTML docs for v1.5.6-rc0
Diffstat (limited to 'gittutorial.html')
| -rw-r--r-- | gittutorial.html | 816 |
1 files changed, 816 insertions, 0 deletions
diff --git a/gittutorial.html b/gittutorial.html new file mode 100644 index 000000000..e531d4704 --- /dev/null +++ b/gittutorial.html @@ -0,0 +1,816 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
+ "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+<meta name="generator" content="AsciiDoc 7.0.2" />
+<style type="text/css">
+/* Debug borders */
+p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {
+/*
+ border: 1px solid red;
+*/
+}
+
+body {
+ margin: 1em 5% 1em 5%;
+}
+
+a { color: blue; }
+a:visited { color: fuchsia; }
+
+em {
+ font-style: italic;
+}
+
+strong {
+ font-weight: bold;
+}
+
+tt {
+ color: navy;
+}
+
+h1, h2, h3, h4, h5, h6 {
+ color: #527bbd;
+ font-family: sans-serif;
+ margin-top: 1.2em;
+ margin-bottom: 0.5em;
+ line-height: 1.3;
+}
+
+h1 {
+ border-bottom: 2px solid silver;
+}
+h2 {
+ border-bottom: 2px solid silver;
+ padding-top: 0.5em;
+}
+
+div.sectionbody {
+ font-family: serif;
+ margin-left: 0;
+}
+
+hr {
+ border: 1px solid silver;
+}
+
+p {
+ margin-top: 0.5em;
+ margin-bottom: 0.5em;
+}
+
+pre {
+ padding: 0;
+ margin: 0;
+}
+
+span#author {
+ color: #527bbd;
+ font-family: sans-serif;
+ font-weight: bold;
+ font-size: 1.2em;
+}
+span#email {
+}
+span#revision {
+ font-family: sans-serif;
+}
+
+div#footer {
+ font-family: sans-serif;
+ font-size: small;
+ border-top: 2px solid silver;
+ padding-top: 0.5em;
+ margin-top: 4.0em;
+}
+div#footer-text {
+ float: left;
+ padding-bottom: 0.5em;
+}
+div#footer-badges {
+ float: right;
+ padding-bottom: 0.5em;
+}
+
+div#preamble,
+div.tableblock, div.imageblock, div.exampleblock, div.verseblock,
+div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
+div.admonitionblock {
+ margin-right: 10%;
+ margin-top: 1.5em;
+ margin-bottom: 1.5em;
+}
+div.admonitionblock {
+ margin-top: 2.5em;
+ margin-bottom: 2.5em;
+}
+
+div.content { /* Block element content. */
+ padding: 0;
+}
+
+/* Block element titles. */
+div.title, caption.title {
+ font-family: sans-serif;
+ font-weight: bold;
+ text-align: left;
+ margin-top: 1.0em;
+ margin-bottom: 0.5em;
+}
+div.title + * {
+ margin-top: 0;
+}
+
+td div.title:first-child {
+ margin-top: 0.0em;
+}
+div.content div.title:first-child {
+ margin-top: 0.0em;
+}
+div.content + div.title {
+ margin-top: 0.0em;
+}
+
+div.sidebarblock > div.content {
+ background: #ffffee;
+ border: 1px solid silver;
+ padding: 0.5em;
+}
+
+div.listingblock > div.content {
+ border: 1px solid silver;
+ background: #f4f4f4;
+ padding: 0.5em;
+}
+
+div.quoteblock > div.content {
+ padding-left: 2.0em;
+}
+div.quoteblock .attribution {
+ text-align: right;
+}
+
+div.admonitionblock .icon {
+ vertical-align: top;
+ font-size: 1.1em;
+ font-weight: bold;
+ text-decoration: underline;
+ color: #527bbd;
+ padding-right: 0.5em;
+}
+div.admonitionblock td.content {
+ padding-left: 0.5em;
+ border-left: 2px solid silver;
+}
+
+div.exampleblock > div.content {
+ border-left: 2px solid silver;
+ padding: 0.5em;
+}
+
+div.verseblock div.content {
+ white-space: pre;
+}
+
+div.imageblock div.content { padding-left: 0; }
+div.imageblock img { border: 1px solid silver; }
+span.image img { border-style: none; }
+
+dl {
+ margin-top: 0.8em;
+ margin-bottom: 0.8em;
+}
+dt {
+ margin-top: 0.5em;
+ margin-bottom: 0;
+ font-style: italic;
+}
+dd > *:first-child {
+ margin-top: 0;
+}
+
+ul, ol {
+ list-style-position: outside;
+}
+ol.olist2 {
+ list-style-type: lower-alpha;
+}
+
+div.tableblock > table {
+ border-color: #527bbd;
+ border-width: 3px;
+}
+thead {
+ font-family: sans-serif;
+ font-weight: bold;
+}
+tfoot {
+ font-weight: bold;
+}
+
+div.hlist {
+ margin-top: 0.8em;
+ margin-bottom: 0.8em;
+}
+td.hlist1 {
+ vertical-align: top;
+ font-style: italic;
+ padding-right: 0.8em;
+}
+td.hlist2 {
+ vertical-align: top;
+}
+
+@media print {
+ div#footer-badges { display: none; }
+}
+include::./stylesheets/xhtml11-manpage.css[]
+/* Workarounds for IE6's broken and incomplete CSS2. */
+
+div.sidebar-content {
+ background: #ffffee;
+ border: 1px solid silver;
+ padding: 0.5em;
+}
+div.sidebar-title, div.image-title {
+ font-family: sans-serif;
+ font-weight: bold;
+ margin-top: 0.0em;
+ margin-bottom: 0.5em;
+}
+
+div.listingblock div.content {
+ border: 1px solid silver;
+ background: #f4f4f4;
+ padding: 0.5em;
+}
+
+div.quoteblock-content {
+ padding-left: 2.0em;
+}
+
+div.exampleblock-content {
+ border-left: 2px solid silver;
+ padding-left: 0.5em;
+}
+</style>
+<title>gittutorial(7)</title>
+</head>
+<body>
+<div id="header">
+<h1>
+gittutorial(7) Manual Page
+</h1>
+<h2>NAME</h2>
+<div class="sectionbody">
+<p>gittutorial -
+ A tutorial introduction to git (for version 1.5.1 or newer)
+</p>
+</div>
+</div>
+<h2>SYNOPSIS</h2>
+<div class="sectionbody">
+<p>git *</p>
+</div>
+<h2>DESCRIPTION</h2>
+<div class="sectionbody">
+<p>This tutorial explains how to import a new project into git, make
+changes to it, and share changes with other developers.</p>
+<p>If you are instead primarily interested in using git to fetch a project,
+for example, to test the latest version, you may prefer to start with
+the first two chapters of <a href="user-manual.html">The Git User's Manual</a>.</p>
+<p>First, note that you can get documentation for a command such as "git
+diff" with:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ man git-diff</tt></pre>
+</div></div>
+<p>It is a good idea to introduce yourself to git with your name and
+public email address before doing any operation. The easiest
+way to do so is:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com</tt></pre>
+</div></div>
+</div>
+<h2>Importing a new project</h2>
+<div class="sectionbody">
+<p>Assume you have a tarball project.tar.gz with your initial work. You
+can place it under git revision control as follows.</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ tar xzf project.tar.gz
+$ cd project
+$ git init</tt></pre>
+</div></div>
+<p>Git will reply</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>Initialized empty Git repository in .git/</tt></pre>
+</div></div>
+<p>You've now initialized the working directory--you may notice a new
+directory created, named ".git".</p>
+<p>Next, tell git to take a snapshot of the contents of all files under the
+current directory (note the <em>.</em>), with <a href="git-add.html">git-add(1)</a>:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git add .</tt></pre>
+</div></div>
+<p>This snapshot is now stored in a temporary staging area which git calls
+the "index". You can permanently store the contents of the index in the
+repository with <a href="git-commit.html">git-commit(1)</a>:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git commit</tt></pre>
+</div></div>
+<p>This will prompt you for a commit message. You've now stored the first
+version of your project in git.</p>
+</div>
+<h2>Making changes</h2>
+<div class="sectionbody">
+<p>Modify some files, then add their updated contents to the index:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git add file1 file2 file3</tt></pre>
+</div></div>
+<p>You are now ready to commit. You can see what is about to be committed
+using <a href="git-diff.html">git-diff(1)</a> with the --cached option:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git diff --cached</tt></pre>
+</div></div>
+<p>(Without --cached, <a href="git-diff.html">git-diff(1)</a> will show you any changes that
+you've made but not yet added to the index.) You can also get a brief
+summary of the situation with <a href="git-status.html">git-status(1)</a>:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git status
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# modified: file1
+# modified: file2
+# modified: file3
+#</tt></pre>
+</div></div>
+<p>If you need to make any further adjustments, do so now, and then add any
+newly modified content to the index. Finally, commit your changes with:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git commit</tt></pre>
+</div></div>
+<p>This will again prompt your for a message describing the change, and then
+record a new version of the project.</p>
+<p>Alternatively, instead of running <tt>git add</tt> beforehand, you can use</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git commit -a</tt></pre>
+</div></div>
+<p>which will automatically notice any modified (but not new) files, add
+them to the index, and commit, all in one step.</p>
+<p>A note on commit messages: Though not required, it's a good idea to
+begin the commit message with a single short (less than 50 character)
+line summarizing the change, followed by a blank line and then a more
+thorough description. Tools that turn commits into email, for
+example, use the first line on the Subject: line and the rest of the
+commit in the body.</p>
+</div>
+<h2>Git tracks content not files</h2>
+<div class="sectionbody">
+<p>Many revision control systems provide an "add" command that tells the
+system to start tracking changes to a new file. Git's "add" command
+does something simpler and more powerful: <tt>git add</tt> is used both for new
+and newly modified files, and in both cases it takes a snapshot of the
+given files and stages that content in the index, ready for inclusion in
+the next commit.</p>
+</div>
+<h2>Viewing project history</h2>
+<div class="sectionbody">
+<p>At any point you can view the history of your changes using</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git log</tt></pre>
+</div></div>
+<p>If you also want to see complete diffs at each step, use</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git log -p</tt></pre>
+</div></div>
+<p>Often the overview of the change is useful to get a feel of
+each step</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git log --stat --summary</tt></pre>
+</div></div>
+</div>
+<h2>Managing branches</h2>
+<div class="sectionbody">
+<p>A single git repository can maintain multiple branches of
+development. To create a new branch named "experimental", use</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git branch experimental</tt></pre>
+</div></div>
+<p>If you now run</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git branch</tt></pre>
+</div></div>
+<p>you'll get a list of all existing branches:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt> experimental
+* master</tt></pre>
+</div></div>
+<p>The "experimental" branch is the one you just created, and the
+"master" branch is a default branch that was created for you
+automatically. The asterisk marks the branch you are currently on;
+type</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git checkout experimental</tt></pre>
+</div></div>
+<p>to switch to the experimental branch. Now edit a file, commit the
+change, and switch back to the master branch:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>(edit file)
+$ git commit -a
+$ git checkout master</tt></pre>
+</div></div>
+<p>Check that the change you made is no longer visible, since it was
+made on the experimental branch and you're back on the master branch.</p>
+<p>You can make a different change on the master branch:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>(edit file)
+$ git commit -a</tt></pre>
+</div></div>
+<p>at this point the two branches have diverged, with different changes
+made in each. To merge the changes made in experimental into master, run</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git merge experimental</tt></pre>
+</div></div>
+<p>If the changes don't conflict, you're done. If there are conflicts,
+markers will be left in the problematic files showing the conflict;</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git diff</tt></pre>
+</div></div>
+<p>will show this. Once you've edited the files to resolve the
+conflicts,</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git commit -a</tt></pre>
+</div></div>
+<p>will commit the result of the merge. Finally,</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ gitk</tt></pre>
+</div></div>
+<p>will show a nice graphical representation of the resulting history.</p>
+<p>At this point you could delete the experimental branch with</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git branch -d experimental</tt></pre>
+</div></div>
+<p>This command ensures that the changes in the experimental branch are
+already in the current branch.</p>
+<p>If you develop on a branch crazy-idea, then regret it, you can always
+delete the branch with</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git branch -D crazy-idea</tt></pre>
+</div></div>
+<p>Branches are cheap and easy, so this is a good way to try something
+out.</p>
+</div>
+<h2>Using git for collaboration</h2>
+<div class="sectionbody">
+<p>Suppose that Alice has started a new project with a git repository in
+/home/alice/project, and that Bob, who has a home directory on the
+same machine, wants to contribute.</p>
+<p>Bob begins with:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git clone /home/alice/project myrepo</tt></pre>
+</div></div>
+<p>This creates a new directory "myrepo" containing a clone of Alice's
+repository. The clone is on an equal footing with the original
+project, possessing its own copy of the original project's history.</p>
+<p>Bob then makes some changes and commits them:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>(edit files)
+$ git commit -a
+(repeat as necessary)</tt></pre>
+</div></div>
+<p>When he's ready, he tells Alice to pull changes from the repository
+at /home/bob/myrepo. She does this with:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ cd /home/alice/project
+$ git pull /home/bob/myrepo master</tt></pre>
+</div></div>
+<p>This merges the changes from Bob's "master" branch into Alice's
+current branch. If Alice has made her own changes in the meantime,
+then she may need to manually fix any conflicts. (Note that the
+"master" argument in the above command is actually unnecessary, as it
+is the default.)</p>
+<p>The "pull" command thus performs two operations: it fetches changes
+from a remote branch, then merges them into the current branch.</p>
+<p>When you are working in a small closely knit group, it is not
+unusual to interact with the same repository over and over
+again. By defining <em>remote</em> repository shorthand, you can make
+it easier:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git remote add bob /home/bob/myrepo</tt></pre>
+</div></div>
+<p>With this, Alice can perform the first operation alone using the
+"git fetch" command without merging them with her own branch,
+using:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git fetch bob</tt></pre>
+</div></div>
+<p>Unlike the longhand form, when Alice fetches from Bob using a
+remote repository shorthand set up with <tt>git remote</tt>, what was
+fetched is stored in a remote tracking branch, in this case
+<tt>bob/master</tt>. So after this:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git log -p master..bob/master</tt></pre>
+</div></div>
+<p>shows a list of all the changes that Bob made since he branched from
+Alice's master branch.</p>
+<p>After examining those changes, Alice
+could merge the changes into her master branch:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git merge bob/master</tt></pre>
+</div></div>
+<p>This <tt>merge</tt> can also be done by <em>pulling from her own remote
+tracking branch</em>, like this:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git pull . remotes/bob/master</tt></pre>
+</div></div>
+<p>Note that git pull always merges into the current branch,
+regardless of what else is given on the command line.</p>
+<p>Later, Bob can update his repo with Alice's latest changes using</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git pull</tt></pre>
+</div></div>
+<p>Note that he doesn't need to give the path to Alice's repository;
+when Bob cloned Alice's repository, git stored the location of her
+repository in the repository configuration, and that location is
+used for pulls:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git config --get remote.origin.url
+/home/alice/project</tt></pre>
+</div></div>
+<p>(The complete configuration created by git-clone is visible using
+"git config -l", and the <a href="git-config.html">git-config(1)</a> man page
+explains the meaning of each option.)</p>
+<p>Git also keeps a pristine copy of Alice's master branch under the
+name "origin/master":</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git branch -r
+ origin/master</tt></pre>
+</div></div>
+<p>If Bob later decides to work from a different host, he can still
+perform clones and pulls using the ssh protocol:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git clone alice.org:/home/alice/project myrepo</tt></pre>
+</div></div>
+<p>Alternatively, git has a native protocol, or can use rsync or http;
+see <a href="git-pull.html">git-pull(1)</a> for details.</p>
+<p>Git can also be used in a CVS-like mode, with a central repository
+that various users push changes to; see <a href="git-push.html">git-push(1)</a> and
+<a href="gitcvs-migration.html">gitcvs-migration(7)</a>[git for CVS users].</p>
+</div>
+<h2>Exploring history</h2>
+<div class="sectionbody">
+<p>Git history is represented as a series of interrelated commits. We
+have already seen that the git log command can list those commits.
+Note that first line of each git log entry also gives a name for the
+commit:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git log
+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+Author: Junio C Hamano <junkio@cox.net>
+Date: Tue May 16 17:18:22 2006 -0700
+
+ merge-base: Clarify the comments on post processing.</tt></pre>
+</div></div>
+<p>We can give this name to git show to see the details about this
+commit.</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7</tt></pre>
+</div></div>
+<p>But there are other ways to refer to commits. You can use any initial
+part of the name that is long enough to uniquely identify the commit:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git show c82a22c39c # the first few characters of the name are
+ # usually enough
+$ git show HEAD # the tip of the current branch
+$ git show experimental # the tip of the "experimental" branch</tt></pre>
+</div></div>
+<p>Every commit usually has one "parent" commit
+which points to the previous state of the project:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git show HEAD^ # to see the parent of HEAD
+$ git show HEAD^^ # to see the grandparent of HEAD
+$ git show HEAD~4 # to see the great-great grandparent of HEAD</tt></pre>
+</div></div>
+<p>Note that merge commits may have more than one parent:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
+$ git show HEAD^2 # show the second parent of HEAD</tt></pre>
+</div></div>
+<p>You can also give commits names of your own; after running</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git-tag v2.5 1b2e1d63ff</tt></pre>
+</div></div>
+<p>you can refer to 1b2e1d63ff by the name "v2.5". If you intend to
+share this name with other people (for example, to identify a release
+version), you should create a "tag" object, and perhaps sign it; see
+<a href="git-tag.html">git-tag(1)</a> for details.</p>
+<p>Any git command that needs to know a commit can take any of these
+names. For example:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git diff v2.5 HEAD # compare the current HEAD to v2.5
+$ git branch stable v2.5 # start a new branch named "stable" based
+ # at v2.5
+$ git reset --hard HEAD^ # reset your current branch and working
+ # directory to its state at HEAD^</tt></pre>
+</div></div>
+<p>Be careful with that last command: in addition to losing any changes
+in the working directory, it will also remove all later commits from
+this branch. If this branch is the only branch containing those
+commits, they will be lost. Also, don't use "git reset" on a
+publicly-visible branch that other developers pull from, as it will
+force needless merges on other developers to clean up the history.
+If you need to undo changes that you have pushed, use <a href="git-revert.html">git-revert(1)</a>
+instead.</p>
+<p>The git grep command can search for strings in any version of your
+project, so</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git grep "hello" v2.5</tt></pre>
+</div></div>
+<p>searches for all occurrences of "hello" in v2.5.</p>
+<p>If you leave out the commit name, git grep will search any of the
+files it manages in your current directory. So</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git grep "hello"</tt></pre>
+</div></div>
+<p>is a quick way to search just the files that are tracked by git.</p>
+<p>Many git commands also take sets of commits, which can be specified
+in a number of ways. Here are some examples with git log:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git log v2.5..v2.6 # commits between v2.5 and v2.6
+$ git log v2.5.. # commits since v2.5
+$ git log --since="2 weeks ago" # commits from the last 2 weeks
+$ git log v2.5.. Makefile # commits since v2.5 which modify
+ # Makefile</tt></pre>
+</div></div>
+<p>You can also give git log a "range" of commits where the first is not
+necessarily an ancestor of the second; for example, if the tips of
+the branches "stable-release" and "master" diverged from a common
+commit some time ago, then</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git log stable..experimental</tt></pre>
+</div></div>
+<p>will list commits made in the experimental branch but not in the
+stable branch, while</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git log experimental..stable</tt></pre>
+</div></div>
+<p>will show the list of commits made on the stable branch but not
+the experimental branch.</p>
+<p>The "git log" command has a weakness: it must present commits in a
+list. When the history has lines of development that diverged and
+then merged back together, the order in which "git log" presents
+those commits is meaningless.</p>
+<p>Most projects with multiple contributors (such as the linux kernel,
+or git itself) have frequent merges, and gitk does a better job of
+visualizing their history. For example,</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ gitk --since="2 weeks ago" drivers/</tt></pre>
+</div></div>
+<p>allows you to browse any commits from the last 2 weeks of commits
+that modified files under the "drivers" directory. (Note: you can
+adjust gitk's fonts by holding down the control key while pressing
+"-" or "+".)</p>
+<p>Finally, most commands that take filenames will optionally allow you
+to precede any filename by a commit, to specify a particular version
+of the file:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git diff v2.5:Makefile HEAD:Makefile.in</tt></pre>
+</div></div>
+<p>You can also use "git show" to see any such file:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git show v2.5:Makefile</tt></pre>
+</div></div>
+</div>
+<h2>Next Steps</h2>
+<div class="sectionbody">
+<p>This tutorial should be enough to perform basic distributed revision
+control for your projects. However, to fully understand the depth
+and power of git you need to understand two simple ideas on which it
+is based:</p>
+<ul>
+<li>
+<p>
+The object database is the rather elegant system used to
+ store the history of your project--files, directories, and
+ commits.
+</p>
+</li>
+<li>
+<p>
+The index file is a cache of the state of a directory tree,
+ used to create commits, check out working directories, and
+ hold the various trees involved in a merge.
+</p>
+</li>
+</ul>
+<p><a href="gittutorial-2.html">gittutorial-2(7)</a>[Part two of this tutorial] explains the object
+database, the index file, and a few other odds and ends that you'll
+need to make the most of git.</p>
+<p>If you don't want to continue with that right away, a few other
+digressions that may be interesting at this point are:</p>
+<ul>
+<li>
+<p>
+<a href="git-format-patch.html">git-format-patch(1)</a>, <a href="git-am.html">git-am(1)</a>: These convert
+ series of git commits into emailed patches, and vice versa,
+ useful for projects such as the linux kernel which rely heavily
+ on emailed patches.
+</p>
+</li>
+<li>
+<p>
+<a href="git-bisect.html">git-bisect(1)</a>: When there is a regression in your
+ project, one way to track down the bug is by searching through
+ the history to find the exact commit that's to blame. Git bisect
+ can help you perform a binary search for that commit. It is
+ smart enough to perform a close-to-optimal search even in the
+ case of complex non-linear history with lots of merged branches.
+</p>
+</li>
+<li>
+<p>
+<a href="everyday.html">Everyday GIT with 20 Commands Or So</a>
+</p>
+</li>
+<li>
+<p>
+<a href="gitcvs-migration.html">gitcvs-migration(7)</a>[git for CVS users].
+</p>
+</li>
+</ul>
+</div>
+<h2>SEE ALSO</h2>
+<div class="sectionbody">
+<p><a href="gittutorial-2.html">gittutorial-2(7)</a>,
+<a href="gitcvs-migration.html">gitcvs-migration(7)</a>,
+<a href="everyday.html">Everyday git</a>,
+<a href="user-manual.html">The Git User's Manual</a></p>
+</div>
+<h2>GIT</h2>
+<div class="sectionbody">
+<p>Part of the <a href="git.html">git(7)</a> suite.</p>
+</div>
+<div id="footer">
+<div id="footer-text">
+Last updated 26-May-2008 01:14:50 UTC
+</div>
+</div>
+</body>
+</html>
|