<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">\r
<head>\r
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />\r
-<meta name="generator" content="AsciiDoc 7.0.1" />\r
+<meta name="generator" content="AsciiDoc 7.0.2" />\r
<style type="text/css">\r
/* Debug borders */\r
p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {\r
<p>At any point you can view the history of your changes using</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git whatchanged</tt></pre>\r
+<pre><tt>$ git log</tt></pre>\r
</div></div>\r
<p>If you also want to see complete diffs at each step, use</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git whatchanged -p</tt></pre>\r
+<pre><tt>$ git log -p</tt></pre>\r
</div></div>\r
</div>\r
<h2>Managing branches</h2>\r
</div></div>\r
<p>This creates a new directory "myrepo" containing a clone of Alice's\r
repository. The clone is on an equal footing with the original\r
-project, posessing its own copy of the original project's history.</p>\r
+project, possessing its own copy of the original project's history.</p>\r
<p>Bob then makes some changes and commits them:</p>\r
<div class="listingblock">\r
<div class="content">\r
<p>This actually pulls changes from the branch in Bob's repository named\r
"master". Alice could request a different branch by adding the name\r
of the branch to the end of the git pull command line.</p>\r
-<p>This merges Bob's changes into her repository; "git whatchanged" will\r
+<p>This merges Bob's changes into her repository; "git log" will\r
now show the new commits. If Alice has made her own changes in the\r
meantime, then Bob's changes will be merged in, and she will need to\r
manually fix any conflicts.</p>\r
of Bob's line of development without doing any merging). Then</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git whatchanged -p master..bob-incoming</tt></pre>\r
+<pre><tt>$ git log -p master..bob-incoming</tt></pre>\r
</div></div>\r
<p>shows a list of all the changes that Bob made since he branched from\r
Alice's master branch.</p>\r
-<p>After examing those changes, and possibly fixing things, Alice can\r
+<p>After examining those changes, and possibly fixing things, Alice can\r
pull the changes into her master branch:</p>\r
<div class="listingblock">\r
<div class="content">\r
that various users push changes to; see <a href="git-push.html">git-push(1)</a> and\r
<a href="cvs-migration.html">git for CVS users</a>.</p>\r
</div>\r
-<h2>Keeping track of history</h2>\r
+<h2>Exploring history</h2>\r
<div class="sectionbody">\r
-<p>Git history is represented as a series of interrelated commits. The\r
-most recent commit in the currently checked-out branch can always be\r
-referred to as HEAD, and the "parent" of any commit can always be\r
-referred to by appending a caret, "^", to the end of the name of the\r
-commit. So, for example,</p>\r
+<p>Git history is represented as a series of interrelated commits. We\r
+have already seen that the git log command can list those commits.\r
+Note that first line of each git log entry also gives a name for the\r
+commit:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>git diff HEAD^ HEAD</tt></pre>\r
+<pre><tt>$ git log\r
+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7\r
+Author: Junio C Hamano <junkio@cox.net>\r
+Date: Tue May 16 17:18:22 2006 -0700\r
+\r
+ merge-base: Clarify the comments on post processing.</tt></pre>\r
</div></div>\r
-<p>shows the difference between the most-recently checked-in state of\r
-the tree and the previous state, and</p>\r
+<p>We can give this name to git show to see the details about this\r
+commit.</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>git diff HEAD^^ HEAD^</tt></pre>\r
+<pre><tt>$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7</tt></pre>\r
</div></div>\r
-<p>shows the difference between that previous state and the state two\r
-commits ago. Also, HEAD~5 can be used as a shorthand for HEAD<sup>^</sup>^^,\r
-and more generally HEAD~n can refer to the nth previous commit.\r
-Commits representing merges have more than one parent, and you can\r
-specify which parent to follow in that case; see\r
-<a href="git-rev-parse.html">git-rev-parse(1)</a>.</p>\r
-<p>The name of a branch can also be used to refer to the most recent\r
-commit on that branch; so you can also say things like</p>\r
+<p>But there other ways to refer to commits. You can use any initial\r
+part of the name that is long enough to uniquely identify the commit:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>git diff HEAD experimental</tt></pre>\r
+<pre><tt>$ git show c82a22c39c # the first few characters of the name are\r
+ # usually enough\r
+$ git show HEAD # the tip of the current branch\r
+$ git show experimental # the tip of the "experimental" branch</tt></pre>\r
</div></div>\r
-<p>to see the difference between the most-recently committed tree in\r
-the current branch and the most-recently committed tree in the\r
-experimental branch.</p>\r
-<p>But you may find it more useful to see the list of commits made in\r
-the experimental branch but not in the current branch, and</p>\r
+<p>Every commit has at least one "parent" commit, which points to the\r
+previous state of the project:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>git whatchanged HEAD..experimental</tt></pre>\r
+<pre><tt>$ git show HEAD^ # to see the parent of HEAD\r
+$ git show HEAD^^ # to see the grandparent of HEAD\r
+$ git show HEAD~4 # to see the great-great grandparent of HEAD</tt></pre>\r
</div></div>\r
-<p>will do that, just as</p>\r
+<p>Note that merge commits may have more than one parent:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>git whatchanged experimental..HEAD</tt></pre>\r
+<pre><tt>$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)\r
+$ git show HEAD^2 # show the second parent of HEAD</tt></pre>\r
</div></div>\r
-<p>will show the list of commits made on the HEAD but not included in\r
-experimental.</p>\r
-<p>You can also give commits convenient names of your own: after running</p>\r
+<p>You can also give commits names of your own; after running</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git-tag v2.5 HEAD^^</tt></pre>\r
+<pre><tt>$ git-tag v2.5 1b2e1d63ff</tt></pre>\r
</div></div>\r
-<p>you can refer to HEAD^^ by the name "v2.5". If you intend to share\r
-this name with other people (for example, to identify a release\r
+<p>you can refer to 1b2e1d63ff by the name "v2.5". If you intend to\r
+share this name with other people (for example, to identify a release\r
version), you should create a "tag" object, and perhaps sign it; see\r
<a href="git-tag.html">git-tag(1)</a> for details.</p>\r
-<p>You can revisit the old state of a tree, and make further\r
-modifications if you wish, using git branch: the command</p>\r
+<p>Any git command that needs to know a commit can take any of these\r
+names. For example:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git branch stable-release v2.5</tt></pre>\r
+<pre><tt>$ git diff v2.5 HEAD # compare the current HEAD to v2.5\r
+$ git branch stable v2.5 # start a new branch named "stable" based\r
+ # at v2.5\r
+$ git reset --hard HEAD^ # reset your current branch and working\r
+ # directory to its state at HEAD^</tt></pre>\r
</div></div>\r
-<p>will create a new branch named "stable-release" starting from the\r
-commit which you tagged with the name v2.5.</p>\r
-<p>You can reset the state of any branch to an earlier commit at any\r
-time with</p>\r
+<p>Be careful with that last command: in addition to losing any changes\r
+in the working directory, it will also remove all later commits from\r
+this branch. If this branch is the only branch containing those\r
+commits, they will be lost. (Also, don't use "git reset" on a\r
+publicly-visible branch that other developers pull from, as git will\r
+be confused by history that disappears in this way.)</p>\r
+<p>The git grep command can search for strings in any version of your\r
+project, so</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git reset --hard v2.5</tt></pre>\r
+<pre><tt>$ git grep "hello" v2.5</tt></pre>\r
+</div></div>\r
+<p>searches for all occurrences of "hello" in v2.5.</p>\r
+<p>If you leave out the commit name, git grep will search any of the\r
+files it manages in your current directory. So</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git grep "hello"</tt></pre>\r
+</div></div>\r
+<p>is a quick way to search just the files that are tracked by git.</p>\r
+<p>Many git commands also take sets of commits, which can be specified\r
+in a number of ways. Here are some examples with git log:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git log v2.5..v2.6 # commits between v2.5 and v2.6\r
+$ git log v2.5.. # commits since v2.5\r
+$ git log --since="2 weeks ago" # commits from the last 2 weeks\r
+$ git log v2.5.. Makefile # commits since v2.5 which modify\r
+ # Makefile</tt></pre>\r
+</div></div>\r
+<p>You can also give git log a "range" of commits where the first is not\r
+necessarily an ancestor of the second; for example, if the tips of\r
+the branches "stable-release" and "master" diverged from a common\r
+commit some time ago, then</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git log stable..experimental</tt></pre>\r
+</div></div>\r
+<p>will list commits made in the experimental branch but not in the\r
+stable branch, while</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git log experimental..stable</tt></pre>\r
+</div></div>\r
+<p>will show the list of commits made on the stable branch but not\r
+the experimental branch.</p>\r
+<p>The "git log" command has a weakness: it must present commits in a\r
+list. When the history has lines of development that diverged and\r
+then merged back together, the order in which "git log" presents\r
+those commits is meaningless.</p>\r
+<p>Most projects with multiple contributors (such as the linux kernel,\r
+or git itself) have frequent merges, and gitk does a better job of\r
+visualizing their history. For example,</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ gitk --since="2 weeks ago" drivers/</tt></pre>\r
+</div></div>\r
+<p>allows you to browse any commits from the last 2 weeks of commits\r
+that modified files under the "drivers" directory. (Note: you can\r
+adjust gitk's fonts by holding down the control key while pressing\r
+"-" or "+".)</p>\r
+<p>Finally, most commands that take filenames will optionally allow you\r
+to precede any filename by a commit, to specify a particular version\r
+of the file:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git diff v2.5:Makefile HEAD:Makefile.in</tt></pre>\r
+</div></div>\r
+<p>You can also use "git cat-file -p" to see any such file:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git cat-file -p v2.5:Makefile</tt></pre>\r
</div></div>\r
-<p>This will remove all later commits from this branch and reset the\r
-working tree to the state it had when the given commit was made. If\r
-this branch is the only branch containing the later commits, those\r
-later changes will be lost. Don't use "git reset" on a\r
-publicly-visible branch that other developers pull from, as git will\r
-be confused by history that disappears in this way.</p>\r
</div>\r
<h2>Next Steps</h2>\r
<div class="sectionbody">\r
-<p>Some good commands to explore next:</p>\r
+<p>This tutorial should be enough to perform basic distributed revision\r
+control for your projects. However, to fully understand the depth\r
+and power of git you need to understand two simple ideas on which it\r
+is based:</p>\r
<ul>\r
<li>\r
<p>\r
-<a href="git-diff.html">git-diff(1)</a>: This flexible command does much more than\r
- we've seen in the few examples above.\r
+The object database is the rather elegant system used to\r
+ store the history of your project—files, directories, and\r
+ commits.\r
</p>\r
</li>\r
<li>\r
<p>\r
+The index file is a cache of the state of a directory tree,\r
+ used to create commits, check out working directories, and\r
+ hold the various trees involved in a merge.\r
+</p>\r
+</li>\r
+</ul>\r
+<p><a href="tutorial-2.html">Part two of this tutorial</a> explains the object\r
+database, the index file, and a few other odds and ends that you'll\r
+need to make the most of git.</p>\r
+<p>If you don't want to consider with that right away, a few other\r
+digressions that may be interesting at this point are:</p>\r
+<ul>\r
+<li>\r
+<p>\r
<a href="git-format-patch.html">git-format-patch(1)</a>, <a href="git-am.html">git-am(1)</a>: These convert\r
series of git commits into emailed patches, and vice versa,\r
useful for projects such as the linux kernel which rely heavily\r
case of complex non-linear history with lots of merged branches.\r
</p>\r
</li>\r
+<li>\r
+<p>\r
+<a href="everyday.html">Everyday GIT with 20 Commands Or So</a>\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<a href="cvs-migration.html">git for CVS users</a>.\r
+</p>\r
+</li>\r
</ul>\r
-<p>Other good starting points include <a href="everyday.html">Everday GIT\r
-with 20 Commands Or So</a> and <a href="cvs-migration.html">git for CVS\r
-users</a>. Also, <a href="core-tutorial.html">A short git tutorial</a> gives an\r
-introduction to lower-level git commands for advanced users and\r
-developers.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 22-Jan-2006 23:54:22 PDT\r
+Last updated 07-Jun-2006 19:51:35 UTC\r
</div>\r
</div>\r
</body>\r
projects / git.git / blobdiff