Merge pull request #46 from randomecho/linkrot
Update progit.org links to git-scm.com book version
This commit is contained in:
commit
aa9f1de00c
144
basic/index.html
144
basic/index.html
@ -5,7 +5,7 @@ layout: reference
|
||||
<div class="box">
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://progit.org/book/ch2-2.html">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository">book</a>
|
||||
</span>
|
||||
Basic Snapshotting
|
||||
</h2>
|
||||
@ -19,13 +19,13 @@ layout: reference
|
||||
<p>
|
||||
An important concept here is that Git has an 'index', which acts as sort
|
||||
of a staging area for your snapshot. This allows you to build up a series
|
||||
of well composed snapshots from changed files in your working directory,
|
||||
of well composed snapshots from changed files in your working directory,
|
||||
rather than having to commit all of the file changes at once.
|
||||
</p>
|
||||
|
||||
<p class="nutshell">
|
||||
<strong>In a nutshell</strong>, you will use <code>git add</code> to start tracking new
|
||||
files and also to stage changes to already tracked files, then
|
||||
files and also to stage changes to already tracked files, then
|
||||
<code>git status</code> and <code>git diff</code> to see what has been
|
||||
modified and staged and finally <code>git commit</code> to record your
|
||||
snapshot into your history. This will be the basic workflow that you use
|
||||
@ -39,7 +39,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-add">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-2.html#tracking_new_files">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Tracking-New-Files">book</a>
|
||||
</span>
|
||||
<a name="add">git add</a>
|
||||
<span class="desc">adds file contents to the staging area</span>
|
||||
@ -47,7 +47,7 @@ layout: reference
|
||||
|
||||
<div class="block">
|
||||
<p>
|
||||
In Git, you have to add file contents to your staging area before you
|
||||
In Git, you have to add file contents to your staging area before you
|
||||
can commit them. If the file is new, you can run <code>git add</code>
|
||||
to initially add the file to your staging area, but even if the file
|
||||
is already "tracked" - ie, it was in your last commit - you still need
|
||||
@ -56,7 +56,7 @@ layout: reference
|
||||
</p>
|
||||
|
||||
<p>Going back to our Hello World example, once we've initiated the project,
|
||||
we would now start adding our files to it and we would do that with
|
||||
we would now start adding our files to it and we would do that with
|
||||
<code>git add</code>. We can use <code>git status</code> to see what the
|
||||
state of our project is.
|
||||
</p>
|
||||
@ -72,7 +72,7 @@ layout: reference
|
||||
<pre>
|
||||
<b>$ git add README hello.rb</b>
|
||||
</pre>
|
||||
|
||||
|
||||
Now if we run <code>git status</code> again, we'll see that they've been
|
||||
added.
|
||||
|
||||
@ -86,8 +86,8 @@ layout: reference
|
||||
It is also common to recursively add all files in a new project by specifying
|
||||
the current working directory like this: <code>git add .</code>. Since Git
|
||||
will recursively add all files under a directory you give it, if you give it
|
||||
the current working directory, it will simply start tracking every file
|
||||
there. In this case, a <code>git add .</code> would have done the same
|
||||
the current working directory, it will simply start tracking every file
|
||||
there. In this case, a <code>git add .</code> would have done the same
|
||||
thing as a <code>git add README hello.rb</code>, or for that matter so would
|
||||
<code>git add *</code>, but that's only because we don't have subdirectories
|
||||
which the <code>*</code> would not recurse into.
|
||||
@ -111,15 +111,15 @@ layout: reference
|
||||
</p>
|
||||
|
||||
<p class="nutshell">
|
||||
<strong>In a nutshell</strong>,
|
||||
you run <code>git add</code> on a file when you want to
|
||||
<strong>In a nutshell</strong>,
|
||||
you run <code>git add</code> on a file when you want to
|
||||
include whatever changes you've made to it in your next commit snapshot.
|
||||
Anything you've changed that is not added will not be included - this means
|
||||
you can craft your snapshots with a bit more precision than most other SCM
|
||||
systems.</p>
|
||||
|
||||
<p>For a very interesting example of using this flexibility to stage only
|
||||
parts of modified files at a time, see the '-p' option to
|
||||
parts of modified files at a time, see the '-p' option to
|
||||
<code>git add</code> in the Pro Git book.</p>
|
||||
|
||||
|
||||
@ -131,7 +131,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-status">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-2.html#checking_the_status_of_your_files">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Checking-the-Status-of-Your-Files">book</a>
|
||||
</span>
|
||||
<a name="status">git status</a>
|
||||
<span class="desc">view the status of your files in the working directory and staging area</span>
|
||||
@ -139,11 +139,11 @@ layout: reference
|
||||
|
||||
<div class="block">
|
||||
<p>As you saw in the <code>git add</code> section, in order to see what the
|
||||
status of your staging area is compared to the code in your working
|
||||
status of your staging area is compared to the code in your working
|
||||
directory, you can run the <code>git status</code> command. I demonstrated
|
||||
using it with the <code>-s</code> option, which gives you short output.
|
||||
Without that flag, the <code>git status</code> command will give you more
|
||||
context and hints. Here is the same status output with and without the
|
||||
context and hints. Here is the same status output with and without the
|
||||
<code>-s</code>. The short output looks like this:
|
||||
</p>
|
||||
|
||||
@ -176,11 +176,11 @@ layout: reference
|
||||
</pre>
|
||||
|
||||
<p>You can easily see how much more compact the short output is, but the
|
||||
long output has useful tips and hints as to what commands you may want to
|
||||
long output has useful tips and hints as to what commands you may want to
|
||||
use next.
|
||||
</p>
|
||||
|
||||
<p>Git will also tell you about files that were deleted since your last
|
||||
<p>Git will also tell you about files that were deleted since your last
|
||||
commit or files that were modified or staged since your last commit.</p>
|
||||
|
||||
<pre>
|
||||
@ -192,7 +192,7 @@ layout: reference
|
||||
You can see there are two columns in the short status output. The first
|
||||
column is for the staging area, the second is for the working directory.
|
||||
So for example, if you have the README file staged and then you modify
|
||||
it again without running <code>git add</code> a second time, you'll see
|
||||
it again without running <code>git add</code> a second time, you'll see
|
||||
this:
|
||||
|
||||
<pre>
|
||||
@ -202,8 +202,8 @@ layout: reference
|
||||
</pre>
|
||||
|
||||
<p class="nutshell">
|
||||
<strong>In a nutshell</strong>,
|
||||
you run <code>git status</code> to see if anything has been modified
|
||||
<strong>In a nutshell</strong>,
|
||||
you run <code>git status</code> to see if anything has been modified
|
||||
and/or staged since your last commit so you can decide if you want to
|
||||
commit a new snapshot and what will be recorded in it.
|
||||
</p>
|
||||
@ -215,7 +215,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-diff">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-2.html#viewing_your_staged_and_unstaged_changes">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Viewing-Your-Staged-and-Unstaged-Changes">book</a>
|
||||
</span>
|
||||
<a name="diff">git diff</a>
|
||||
<span class="desc">shows diff of what is staged and what is modified but unstaged</span>
|
||||
@ -223,7 +223,7 @@ layout: reference
|
||||
|
||||
<div class="block">
|
||||
<p>There are two main uses of the <code>git diff</code> command. One use we
|
||||
will describe here, the other we will describe later in the
|
||||
will describe here, the other we will describe later in the
|
||||
<a href="/inspect">"Inspection and Comparison"</a>
|
||||
section. The way we're going to use it here is to describe the
|
||||
changes that are staged or modified on disk but unstaged.</p>
|
||||
@ -250,16 +250,16 @@ index d62ac43..8d15d50 100644
|
||||
+++ b/hello.rb</span>
|
||||
<span class="lblue">@@ -1,7 +1,7 @@</span>
|
||||
class HelloWorld
|
||||
|
||||
|
||||
def self.hello
|
||||
<span class="red">- puts "hello world"</span>
|
||||
<span class="green">+ puts "hola mundo"</span>
|
||||
end
|
||||
|
||||
|
||||
end
|
||||
</pre>
|
||||
|
||||
<p>So where <code>git status</code> will show you what files have changed
|
||||
<p>So where <code>git status</code> will show you what files have changed
|
||||
and/or been staged since your last commit, <code>git diff</code> will
|
||||
show you what those changes actually are, line by line. It's generally
|
||||
a good follow-up command to <code>git status</code>
|
||||
@ -271,9 +271,9 @@ index d62ac43..8d15d50 100644
|
||||
</h4>
|
||||
|
||||
<p>The <code>git diff --cached</code> command will show you what contents
|
||||
have been staged. That is, this will show you the changes that will
|
||||
have been staged. That is, this will show you the changes that will
|
||||
currently go into the next commit snapshot. So, if you were to stage
|
||||
the change to <code>hello.rb</code> in the example above,
|
||||
the change to <code>hello.rb</code> in the example above,
|
||||
<code>git diff</code> by itself won't show you any output because it will
|
||||
only show you what is <i>not yet</i> staged.
|
||||
</p>
|
||||
@ -288,7 +288,7 @@ index d62ac43..8d15d50 100644
|
||||
<b>$ </b>
|
||||
</pre>
|
||||
|
||||
<p>If you want to see the staged changes, you can run
|
||||
<p>If you want to see the staged changes, you can run
|
||||
<code>git diff --cached</code> instead.</p>
|
||||
|
||||
<pre>
|
||||
@ -303,12 +303,12 @@ index d62ac43..8d15d50 100644
|
||||
+++ b/hello.rb</span>
|
||||
<span class="lblue">@@ -1,7 +1,7 @@</span>
|
||||
class HelloWorld
|
||||
|
||||
|
||||
def self.hello
|
||||
<span class="red">- puts "hello world"</span>
|
||||
<span class="green">+ puts "hola mundo"</span>
|
||||
end
|
||||
|
||||
|
||||
end
|
||||
</pre>
|
||||
|
||||
@ -320,7 +320,7 @@ index d62ac43..8d15d50 100644
|
||||
<p>If you want to see both staged and unstaged changes together, you
|
||||
can run <code>git diff HEAD</code> - this basically means you want to
|
||||
see the difference between your working directory and the last commit,
|
||||
ignoring the staging area. If we make another change to our
|
||||
ignoring the staging area. If we make another change to our
|
||||
<code>hello.rb</code> file then we'll have some changes staged and some
|
||||
changes unstaged. Here are what all three <code>diff</code> commands
|
||||
will show you:</p>
|
||||
@ -333,12 +333,12 @@ index 4f40006..2ae9ba4 100644
|
||||
+++ b/hello.rb</span>
|
||||
<span class="lblue">@@ -1,7 +1,7 @@</span>
|
||||
class HelloWorld
|
||||
|
||||
|
||||
<span class="green">+ # says hello</span>
|
||||
def self.hello
|
||||
puts "hola mundo"
|
||||
end
|
||||
|
||||
|
||||
end
|
||||
<b>$ git diff --cached</b>
|
||||
<span class="umber">diff --git a/hello.rb b/hello.rb
|
||||
@ -347,12 +347,12 @@ index 2aabb6e..4f40006 100644
|
||||
+++ b/hello.rb</span>
|
||||
<span class="lblue">@@ -1,7 +1,7 @@</span>
|
||||
class HelloWorld
|
||||
|
||||
|
||||
def self.hello
|
||||
<span class="red">- puts "hello world"</span>
|
||||
<span class="green">+ puts "hola mundo"</span>
|
||||
end
|
||||
|
||||
|
||||
end
|
||||
<b>$ git diff HEAD</b>
|
||||
<span class="umber">diff --git a/hello.rb b/hello.rb
|
||||
@ -361,13 +361,13 @@ index 2aabb6e..2ae9ba4 100644
|
||||
+++ b/hello.rb</span>
|
||||
<span class="lblue">@@ -1,7 +1,8 @@</span>
|
||||
class HelloWorld
|
||||
|
||||
|
||||
<span class="green">+ # says hello</span>
|
||||
def self.hello
|
||||
<span class="red">- puts "hello world"</span>
|
||||
<span class="green">+ puts "hola mundo"</span>
|
||||
end
|
||||
|
||||
|
||||
end
|
||||
</pre>
|
||||
|
||||
@ -381,7 +381,7 @@ index 2aabb6e..2ae9ba4 100644
|
||||
option, which will give us a summary of changes instead. Here is the
|
||||
same example as above, but using the <code>--stat</code> option instead.
|
||||
</p>
|
||||
|
||||
|
||||
<pre>
|
||||
<b>$ git status -s</b>
|
||||
<span class="green">M</span><span class="red">M</span> hello.rb
|
||||
@ -403,10 +403,10 @@ index 2aabb6e..2ae9ba4 100644
|
||||
|
||||
|
||||
<p class="nutshell">
|
||||
<strong>In a nutshell</strong>,
|
||||
<strong>In a nutshell</strong>,
|
||||
you run <code>git diff</code> to see details of the <code>git status</code>
|
||||
command - <i>how</i> files have been modified or staged on a line by line
|
||||
basis.
|
||||
basis.
|
||||
</p>
|
||||
|
||||
|
||||
@ -417,7 +417,7 @@ index 2aabb6e..2ae9ba4 100644
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-commit">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-2.html#committing_your_changes">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Committing-Your-Changes">book</a>
|
||||
</span>
|
||||
<a name="commit">git commit</a>
|
||||
<span class="desc">records a snapshot of the staging area</span>
|
||||
@ -425,7 +425,7 @@ index 2aabb6e..2ae9ba4 100644
|
||||
|
||||
<div class="block">
|
||||
|
||||
<p>Now that you have staged the content you want to snapshot with the
|
||||
<p>Now that you have staged the content you want to snapshot with the
|
||||
<code>git add</code> command, you run <code>git commit</code> to actually
|
||||
record the snapshot.
|
||||
Git records your name and email address with every commit you make,
|
||||
@ -438,7 +438,7 @@ index 2aabb6e..2ae9ba4 100644
|
||||
</pre>
|
||||
|
||||
<p>Let's stage and commit all the changes to our
|
||||
<code>hello.rb</code> file. In this first example, we'll use the
|
||||
<code>hello.rb</code> file. In this first example, we'll use the
|
||||
<code>-m</code> option to provide the commit message on the command line.
|
||||
</p>
|
||||
|
||||
@ -488,10 +488,10 @@ nothing to commit (working directory clean)
|
||||
the output of the <code>git status</code> command in there for you as
|
||||
a reminder of what you have modified and staged.</p>
|
||||
|
||||
<p>In general, it's very important to write a good commit message.
|
||||
<p>In general, it's very important to write a good commit message.
|
||||
For open source projects, it's generally a rule to write your message
|
||||
more or less in this format:</p>
|
||||
|
||||
|
||||
<pre>
|
||||
Short (50 chars or less) summary of changes
|
||||
|
||||
@ -531,7 +531,7 @@ Further paragraphs come after blank lines.
|
||||
four commits of logically separate changes so that your work may be more
|
||||
easily peer reviewed. Since there is a separation between committing and
|
||||
pushing those changes, do take the time to make it easier for the people
|
||||
you are working with to see what you've done by putting each logically
|
||||
you are working with to see what you've done by putting each logically
|
||||
separate change in a separate commit with a nice commit message so it
|
||||
is easier for them to see what you are doing and why.</p>
|
||||
|
||||
@ -540,8 +540,8 @@ Further paragraphs come after blank lines.
|
||||
<small>automatically stage all tracked, modified files before the commit</small>
|
||||
</h4>
|
||||
|
||||
<p>If you think the <code>git add</code> stage of the workflow is too
|
||||
cumbersome, Git allows you to skip that part with the <code>-a</code>
|
||||
<p>If you think the <code>git add</code> stage of the workflow is too
|
||||
cumbersome, Git allows you to skip that part with the <code>-a</code>
|
||||
option. This basically tells Git to run <code>git add</code> on any file
|
||||
that is "tracked" - that is, any file that was in your last commit and
|
||||
has been modified. This allows you to do a more Subversion style workflow
|
||||
@ -569,7 +569,7 @@ Further paragraphs come after blank lines.
|
||||
1 files changed, 2 insertions(+), 1 deletions(-)
|
||||
</pre>
|
||||
|
||||
<p>Notice how if you don't stage any changes and then run
|
||||
<p>Notice how if you don't stage any changes and then run
|
||||
<code>git commit</code>, Git will simply give you the output of the
|
||||
<code>git status</code> command, reminding you that nothing is staged.
|
||||
I've highlighted the important part of that message, saying that nothing
|
||||
@ -584,7 +584,7 @@ Further paragraphs come after blank lines.
|
||||
to actually record the snapshot forever.</p>
|
||||
|
||||
<p class="nutshell">
|
||||
<strong>In a nutshell</strong>,
|
||||
<strong>In a nutshell</strong>,
|
||||
you run <code>git commit</code> to record the snapshot of your staged
|
||||
content. This snapshot can then be compared, shared and reverted to
|
||||
if you need to.
|
||||
@ -597,7 +597,7 @@ Further paragraphs come after blank lines.
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-reset">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-4.html#unstaging_a_staged_file">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/ch2-4.html#Unstaging-a-Staged-File">book</a>
|
||||
</span>
|
||||
<a name="reset">git reset HEAD</a>
|
||||
<span class="desc">unstage changes that you have staged</span>
|
||||
@ -605,18 +605,18 @@ Further paragraphs come after blank lines.
|
||||
|
||||
<div class="block">
|
||||
<p><code>git reset</code> is probably the most confusing command written
|
||||
by humans. I've been using Git for years, even wrote a book on it and I
|
||||
still get confused by what it is going to do at times. So, I'll just
|
||||
tell you the three specific invocations of it that are generally
|
||||
helpful and ask you to blindly use it as I do - because it can be
|
||||
by humans. I've been using Git for years, even wrote a book on it and I
|
||||
still get confused by what it is going to do at times. So, I'll just
|
||||
tell you the three specific invocations of it that are generally
|
||||
helpful and ask you to blindly use it as I do - because it can be
|
||||
very useful.
|
||||
</p>
|
||||
|
||||
<p>In this case, we can use it to unstage something that you have
|
||||
<p>In this case, we can use it to unstage something that you have
|
||||
accidentally staged. Let's say that you have modified two files and want
|
||||
to record them into two different commits. You should stage and commit
|
||||
one, then stage and commit the other. If you accidentally stage both of
|
||||
them, how do you <i>un-</i>stage one? You do it with
|
||||
them, how do you <i>un-</i>stage one? You do it with
|
||||
<code>git reset HEAD -- file</code>. Technically here you don't have to
|
||||
add the <code>--</code> - it is used to tell Git when you have stopped
|
||||
listing options and are now listing file paths, but it's probably good to
|
||||
@ -659,9 +659,9 @@ M hello.rb
|
||||
|
||||
<p class="tip">
|
||||
If you want to be able to just run <code>git unstage</code>, you can easily
|
||||
setup an alias in Git. Just run
|
||||
<code>git config --global alias.unstage "reset HEAD"</code>.
|
||||
Once you have run that, you can then just run
|
||||
setup an alias in Git. Just run
|
||||
<code>git config --global alias.unstage "reset HEAD"</code>.
|
||||
Once you have run that, you can then just run
|
||||
<code>git unstage [file]</code> instead.
|
||||
</p>
|
||||
|
||||
@ -683,7 +683,7 @@ M hello.rb
|
||||
</pre>
|
||||
|
||||
<p class="nutshell">
|
||||
<strong>In a nutshell</strong>,
|
||||
<strong>In a nutshell</strong>,
|
||||
you run <code>git reset HEAD</code> to unstage files that you previously
|
||||
ran <code>git add</code> on and wish to not include in the next commit
|
||||
snapshot</p>
|
||||
@ -695,7 +695,7 @@ M hello.rb
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a href="http://git-scm.com/docs/git-rm">docs</a>
|
||||
<a href="http://progit.org/book/ch2-2.html#removing_files">book</a>
|
||||
<a href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Removing-Files">book</a>
|
||||
</span>
|
||||
<a name="rm-mv">git rm</a>
|
||||
<span class="desc">remove files from the staging area</span>
|
||||
@ -703,18 +703,18 @@ M hello.rb
|
||||
|
||||
<div class="block">
|
||||
|
||||
<p><code>git rm</code> will remove entries from the staging area.
|
||||
This is a bit different from <code>git reset HEAD</code> which "unstages"
|
||||
files. By "unstage" I mean it reverts the staging area to what was
|
||||
there before we started modifying things. <code>git rm</code> on the
|
||||
other hand just kicks the file off the stage entirely, so that it's not
|
||||
<p><code>git rm</code> will remove entries from the staging area.
|
||||
This is a bit different from <code>git reset HEAD</code> which "unstages"
|
||||
files. By "unstage" I mean it reverts the staging area to what was
|
||||
there before we started modifying things. <code>git rm</code> on the
|
||||
other hand just kicks the file off the stage entirely, so that it's not
|
||||
included in the next commit snapshot, thereby effectively deleting it.</p>
|
||||
|
||||
<p>By default, a <code>git rm file</code> will remove the file from the
|
||||
<p>By default, a <code>git rm file</code> will remove the file from the
|
||||
staging area entirely and also off your disk (the working directory). To
|
||||
leave the file in the working directory, you can use <code>git rm --cached
|
||||
</code>.</p>
|
||||
|
||||
|
||||
<h4>
|
||||
git mv
|
||||
<small>git rm --cached orig; mv orig new; git add new</small>
|
||||
@ -725,7 +725,7 @@ M hello.rb
|
||||
Instead, it just tracks the snapshots and then figures out what files were
|
||||
likely renamed by comparing snapshots. If a file was removed from one
|
||||
snapshot and another file was added to the next one and the contents are
|
||||
similar, Git figures it was most likely a rename. So, although the
|
||||
similar, Git figures it was most likely a rename. So, although the
|
||||
<code>git mv</code> command exists, it is superfluous - all it does is a
|
||||
<code>git rm --cached</code>, moves the file on disk, then runs a
|
||||
<code>git add</code> on the new file. You don't really need to use it, but
|
||||
@ -739,8 +739,8 @@ M hello.rb
|
||||
from your index, too.</p>
|
||||
|
||||
<p class="nutshell">
|
||||
<strong>In a nutshell</strong>,
|
||||
you run <code>git rm</code> to remove files from being tracked in Git. It
|
||||
<strong>In a nutshell</strong>,
|
||||
you run <code>git rm</code> to remove files from being tracked in Git. It
|
||||
will also remove them from your working directory.</p>
|
||||
</p>
|
||||
|
||||
|
@ -5,7 +5,7 @@ layout: reference
|
||||
<div class="box">
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://progit.org/book/ch3-0.html">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Branching">book</a>
|
||||
</span>
|
||||
Branching and Merging
|
||||
</h2>
|
||||
@ -39,7 +39,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-branch">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch3-2.html">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Branching-What-a-Branch-Is">book</a>
|
||||
</span>
|
||||
<a name="branch">git branch</a>
|
||||
<span class="desc">list, create and manage working contexts</span>
|
||||
@ -50,7 +50,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-checkout">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch3-2.html">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging">book</a>
|
||||
</span>
|
||||
<a name="checkout">git checkout</a>
|
||||
<span class="desc">switch to a new branch context</span>
|
||||
@ -72,7 +72,7 @@ layout: reference
|
||||
<p>Without arguments, <code>git branch</code> will list out the local
|
||||
branches that you have. The branch that you are currently working on will
|
||||
have a star next to it and if you have
|
||||
<a href="http://progit.org/book/ch7-1.html#colors_in_git">coloring turned on</a>,
|
||||
<a href="http://git-scm.com/book/en/Customizing-Git-Git-Configuration#Colors-in-Git">coloring turned on</a>,
|
||||
will show the current branch in green.
|
||||
</p>
|
||||
|
||||
@ -227,7 +227,7 @@ Deleted branch testing (was 78b2670).
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-merge">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch3-2.html#basic_merging">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging#Basic-Merging">book</a>
|
||||
</span>
|
||||
<a name="merge">git merge</a>
|
||||
<span class="desc">merge a branch context into your current one</span>
|
||||
@ -473,7 +473,7 @@ M README
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-log">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch6-1.html#commit_ranges">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Tools-Revision-Selection#Commit-Ranges">book</a>
|
||||
</span>
|
||||
<a name="log">git log</a>
|
||||
<span class="desc">show commit history of a branch</span>
|
||||
@ -696,7 +696,7 @@ ab5ab4c added erlang
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-tag">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-6.html">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Tagging">book</a>
|
||||
</span>
|
||||
<a name="tag">git tag</a>
|
||||
<span class="desc">tag a point in history as important</span>
|
||||
|
@ -24,7 +24,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-init">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-1.html#initializing_a_repository_in_an_existing_directory">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository#Initializing-a-Repository-in-an-Existing-Directory">book</a>
|
||||
</span>
|
||||
<a name="init">git init</a>
|
||||
<span class="desc">initializes a directory as a Git repository</span>
|
||||
@ -75,7 +75,7 @@ Initialized empty Git repository in /opt/konichiwa/.git/
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-clone">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-1.html#cloning_an_existing_repository">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository#Cloning-an-Existing-Repository">book</a>
|
||||
</span>
|
||||
<a name="clone">git clone</a>
|
||||
<span class="desc">copy a git repository so you can add to it</span>
|
||||
@ -84,7 +84,7 @@ Initialized empty Git repository in /opt/konichiwa/.git/
|
||||
<p>
|
||||
If you need to collaborate with someone on a project, or if you want to
|
||||
get a copy of a project so you can look at or use the code, you will
|
||||
clone it. You simply run the <code>git clone [url]</code> command with
|
||||
clone it. You simply run the <code>git clone [url]</code> command with
|
||||
the URL of the project you want to copy.
|
||||
</p>
|
||||
|
||||
@ -120,14 +120,14 @@ config index <span class="blue">objects</span>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
By default, Git will create a directory that is the same name as the
|
||||
By default, Git will create a directory that is the same name as the
|
||||
project in the URL you give it - basically whatever is after the last slash
|
||||
of the URL. If you want something different, you can just put it at the
|
||||
end of the command, after the URL.
|
||||
</p>
|
||||
|
||||
<p class="nutshell">
|
||||
<strong>In a nutshell</strong>, you use <code>git clone</code> to get a
|
||||
<strong>In a nutshell</strong>, you use <code>git clone</code> to get a
|
||||
local copy of a Git repository so you can look at it or start modifying
|
||||
it.</p>
|
||||
|
||||
|
28
index.html
28
index.html
@ -16,9 +16,9 @@ layout: reference
|
||||
Each section will link to the next section, so it can be used
|
||||
as a tutorial. Every page will also link to more in-depth
|
||||
Git documentation such as the official manual pages and relevant
|
||||
sections in the <a href="http://progit.org">Pro Git book</a>,
|
||||
so you can learn more about any of
|
||||
the commands. First, we'll start with thinking about source code
|
||||
sections in the <a href="http://git-scm.com/book">Pro Git book</a>,
|
||||
so you can learn more about any of
|
||||
the commands. First, we'll start with thinking about source code
|
||||
management like Git does.
|
||||
</p>
|
||||
</div>
|
||||
@ -29,7 +29,7 @@ layout: reference
|
||||
<div class="block">
|
||||
<p>
|
||||
The first thing that is important to understand about Git is
|
||||
that it thinks about version control very differently than
|
||||
that it thinks about version control very differently than
|
||||
Subversion or Perforce or whatever SCM you may be used to. It
|
||||
is often easier to learn Git by trying to forget your assumptions
|
||||
about how version control works and try to think about it in the
|
||||
@ -37,16 +37,16 @@ layout: reference
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Let's start from scratch. Assume you are designing a new source
|
||||
Let's start from scratch. Assume you are designing a new source
|
||||
code management system. How did you do basic version control before
|
||||
you used a tool for it? Chances are that you simply copied your
|
||||
you used a tool for it? Chances are that you simply copied your
|
||||
project directory to save what it looked like at that point.
|
||||
</p>
|
||||
|
||||
<pre> $ cp -R project project.bak </pre>
|
||||
|
||||
<p>
|
||||
That way, you can easily revert files that get messed up later, or
|
||||
That way, you can easily revert files that get messed up later, or
|
||||
see what you have changed by comparing what the project looks like
|
||||
now to what it looked like when you copied it.
|
||||
</p>
|
||||
@ -59,8 +59,8 @@ layout: reference
|
||||
<pre> $ cp -R project project.2010-06-01.bak </pre>
|
||||
|
||||
<p>
|
||||
In that case, you may have a bunch of snapshots of your project that
|
||||
you can compare and inspect from. You can even use this model to
|
||||
In that case, you may have a bunch of snapshots of your project that
|
||||
you can compare and inspect from. You can even use this model to
|
||||
fairly effectively share changes with someone. If you zip up your
|
||||
project at a known state and put it on your website, other developers
|
||||
can download that, change it and send you a patch pretty easily.
|
||||
@ -77,7 +77,7 @@ layout: reference
|
||||
|
||||
<p>
|
||||
Now the original developer can apply that patch to their copy of the
|
||||
project and they have your changes. This is how many open source
|
||||
project and they have your changes. This is how many open source
|
||||
projects have been collaborated on for several years.
|
||||
</p>
|
||||
|
||||
@ -91,10 +91,10 @@ layout: reference
|
||||
|
||||
<p>
|
||||
This is essentially what Git is. You tell Git you want to save a snapshot
|
||||
of your project with the <code>git commit</code> command and it basically
|
||||
records a manifest of what all of the files in your project look like at
|
||||
of your project with the <code>git commit</code> command and it basically
|
||||
records a manifest of what all of the files in your project look like at
|
||||
that point. Then most of the commands work with those manifests to see
|
||||
how they differ or pull content out of them, etc.
|
||||
how they differ or pull content out of them, etc.
|
||||
</p>
|
||||
|
||||
<center><img src="./images/snapshots.png"/></center>
|
||||
@ -102,7 +102,7 @@ layout: reference
|
||||
<p>
|
||||
If you think about Git
|
||||
as a tool for storing and comparing and merging snapshots of your project,
|
||||
it may be easier to understand what is going on and how to do things
|
||||
it may be easier to understand what is going on and how to do things
|
||||
properly.
|
||||
</p>
|
||||
|
||||
|
@ -5,7 +5,7 @@ layout: reference
|
||||
<div class="box">
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://progit.org/book/ch2-3.html">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-History">book</a>
|
||||
</span>
|
||||
Inspection and Comparison
|
||||
</h2>
|
||||
@ -31,7 +31,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-log">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-3.html">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-History#Limiting-Log-Output">book</a>
|
||||
</span>
|
||||
<a name="log">git log</a>
|
||||
<span class="desc">filter your commit history</span>
|
||||
@ -310,7 +310,7 @@ Date: Fri Jun 4 12:58:53 2010 +0200
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-diff">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch5-3.html#determining_what_is_introduced">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project#Determining-What-Is-Introduced">book</a>
|
||||
</span>
|
||||
<a name="diff">git diff</a>
|
||||
<span class="desc"></span>
|
||||
@ -471,4 +471,4 @@ index bb86f00..192151c 100644
|
||||
</div>
|
||||
|
||||
<p>And that's it! For more information, try reading the
|
||||
<a href="http://progit.org">Pro Git book</a>.</p>
|
||||
<a href="http://git-scm.com/book/">Pro Git book</a>.</p>
|
||||
|
@ -5,7 +5,7 @@ layout: reference
|
||||
<div class="box">
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://progit.org/book/ch2-5.html">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Working-with-Remotes">book</a>
|
||||
</span>
|
||||
Sharing and Updating Projects
|
||||
</h2>
|
||||
@ -44,7 +44,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-remote">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-5.html#showing_your_remotes">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Working-with-Remotes#Showing-Your-Remotes">book</a>
|
||||
</span>
|
||||
<a name="remote">git remote</a>
|
||||
<span class="desc">list, add and delete remote repository aliases</span>
|
||||
@ -160,7 +160,7 @@ github git@github.com:schacon/hw.git (push)
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-fetch">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-5.html#fetching_and_pulling_from_your_remotes">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Working-with-Remotes#Fetching-and-Pulling-from-Your-Remotes">book</a>
|
||||
</span>
|
||||
<a name="fetch">git fetch</a>
|
||||
<span class="desc">download new branches and data from a remote repository</span>
|
||||
@ -171,7 +171,7 @@ github git@github.com:schacon/hw.git (push)
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-pull">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Working-with-Remotes#Fetching-and-Pulling-from-Your-Remotes">book</a>
|
||||
</span>
|
||||
<a name="pull">git pull</a>
|
||||
<span class="desc">fetch from a remote repo and try to merge into the current branch</span>
|
||||
@ -255,7 +255,7 @@ From github.com:schacon/hw
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://git-scm.com/docs/git-push">docs</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-5.html#pushing_to_your_remotes">book</a>
|
||||
<a target="new" href="http://git-scm.com/book/en/Git-Basics-Working-with-Remotes#Pushing-to-Your-Remotes">book</a>
|
||||
</span>
|
||||
<a name="push">git push</a>
|
||||
<span class="desc">push your new branches and data to a remote repository</span>
|
||||
|
Loading…
Reference in New Issue
Block a user