updated all the book urls
This commit is contained in:
parent
af3721dd12
commit
7057ccb078
@ -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://progit.org/book/ch3-0.html">book</a>
|
||||
</span>
|
||||
Branching and Merging
|
||||
</h2>
|
||||
@ -14,21 +14,21 @@ layout: reference
|
||||
version control systems, it's probably helpful to forget most of what you
|
||||
think about branches - in fact, it may be more helpful to think of them
|
||||
practically as <i>contexts</i> since that is how you will most often be
|
||||
using them. When you checkout different branches, you change contexts
|
||||
using them. When you checkout different branches, you change contexts
|
||||
that you are working in and you can quickly context-switch back and forth
|
||||
between several different branches.
|
||||
</p>
|
||||
|
||||
<p class="nutshell">
|
||||
<b>In a nutshell</b> you can create a branch with
|
||||
<b>In a nutshell</b> you can create a branch with
|
||||
<code>git branch (branchname)</code>, switch into that context with
|
||||
<code>git checkout (branchname)</code>, record commit snapshots while
|
||||
in that context, then can switch back and forth easily. When you switch
|
||||
branches, Git replaces your working directory with the snapshot of the
|
||||
latest commit on that branch so you don't have to have multiple directories
|
||||
for multiple branches. You merge branches together with
|
||||
for multiple branches. You merge branches together with
|
||||
<code>git merge</code>. You can easily merge multiple times from the same
|
||||
branch over time, or alternately you can choose to delete a branch
|
||||
branch over time, or alternately you can choose to delete a branch
|
||||
immediately after merging it.
|
||||
</p>
|
||||
|
||||
@ -39,7 +39,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-branch.html">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch3-2.html">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://www.kernel.org/pub/software/scm/git/docs/git-checkout.html">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch3-2.html">book</a>
|
||||
</span>
|
||||
<a name="checkout">git checkout</a>
|
||||
<span class="desc">switch to a new branch context</span>
|
||||
@ -69,10 +69,10 @@ layout: reference
|
||||
<small>list your available branches</small>
|
||||
</h4>
|
||||
|
||||
<p>Without arguments, <code>git branch</code> will list out the local
|
||||
<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>,
|
||||
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>,
|
||||
will show the current branch in green.
|
||||
</p>
|
||||
|
||||
@ -105,7 +105,7 @@ $ git branch
|
||||
|
||||
<p>Now we can see that we have a new branch. When you create a branch this
|
||||
way it creates the branch at your last commit so if you record some commits
|
||||
at this point and then switch to 'testing', it will revert your working
|
||||
at this point and then switch to 'testing', it will revert your working
|
||||
directory context back to when you created the branch in the first place -
|
||||
you can think of it like a bookmark for where you currently are. Let's see
|
||||
this in action - we use <code>git checkout (branch)</code> to switch the
|
||||
@ -188,20 +188,20 @@ README hello.rb more.txt test.txt
|
||||
contexts we can switch between.</p>
|
||||
|
||||
<p>
|
||||
If you start on work it is very useful to
|
||||
If you start on work it is very useful to
|
||||
always start it in a branch (because it's fast and easy to do) and then
|
||||
merge it in and delete the branch when you're done. That way if what you're
|
||||
working on doesn't work out you can easily discard it and if you're forced
|
||||
to switch back to a more stable context your work in progress is easy to put
|
||||
aside and then come back to.</p>
|
||||
|
||||
|
||||
<h4>
|
||||
git branch -d (branchname)
|
||||
<small>delete a branch</small>
|
||||
</h4>
|
||||
|
||||
<p>If we want to delete a branch (such as the 'testing' branch in the
|
||||
previous example, since there is no unique work on it),
|
||||
<p>If we want to delete a branch (such as the 'testing' branch in the
|
||||
previous example, since there is no unique work on it),
|
||||
we can run <code>git branch -d (branch)</code> to remove it.
|
||||
|
||||
<pre>
|
||||
@ -215,8 +215,8 @@ Deleted branch testing (was 78b2670).
|
||||
</pre>
|
||||
|
||||
<p class="nutshell">
|
||||
<b>In a nutshell</b> you use <code>git branch</code> to list your
|
||||
current branches, create new branches and delete unnecessary or
|
||||
<b>In a nutshell</b> you use <code>git branch</code> to list your
|
||||
current branches, create new branches and delete unnecessary or
|
||||
already merged branches.
|
||||
</p>
|
||||
|
||||
@ -227,20 +227,20 @@ Deleted branch testing (was 78b2670).
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-merge.html">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch3-2.html#basic_merging">book</a>
|
||||
</span>
|
||||
<a name="merge">git merge</a>
|
||||
<span class="desc">merge a branch context into your current one</span>
|
||||
</h2>
|
||||
|
||||
<div class="block">
|
||||
<p>Once you have work isolated in a branch, you will eventually want to
|
||||
<p>Once you have work isolated in a branch, you will eventually want to
|
||||
incorporate it into your main branch. You can merge any branch into your
|
||||
current branch with the <code>git merge</code> command. Let's take as a
|
||||
current branch with the <code>git merge</code> command. Let's take as a
|
||||
simple example the 'removals' branch from above. If we create a branch
|
||||
and remove files in it and commit our removals to that branch, it is
|
||||
and remove files in it and commit our removals to that branch, it is
|
||||
isolated from our main ('master', in this case) branch. To include those
|
||||
deletions in your 'master' branch, you can just merge in the 'removals'
|
||||
deletions in your 'master' branch, you can just merge in the 'removals'
|
||||
branch.
|
||||
</p>
|
||||
|
||||
@ -266,7 +266,7 @@ Fast-forward
|
||||
more complex merges
|
||||
</h4>
|
||||
|
||||
<p>Of course, this doesn't just work for simple file additions and
|
||||
<p>Of course, this doesn't just work for simple file additions and
|
||||
deletions. Git will merge file modifications as well - in fact, it's very
|
||||
good at it. For example, let's see what happens when we edit a file in
|
||||
one branch and in another branch we rename it and then edit it and then
|
||||
@ -286,8 +286,8 @@ end
|
||||
HelloWorld.hello
|
||||
</pre>
|
||||
|
||||
<p>So first we're going to create a new branch named 'change_class' and
|
||||
switch to it so your class renaming changes are isolated. I'm going to
|
||||
<p>So first we're going to create a new branch named 'change_class' and
|
||||
switch to it so your class renaming changes are isolated. I'm going to
|
||||
change each instance of 'HelloWorld' to 'HiWorld'.</p>
|
||||
|
||||
<pre>
|
||||
@ -301,10 +301,10 @@ class HiWorld
|
||||
[change_class 3467b0a] changed the class name
|
||||
1 files changed, 2 insertions(+), 4 deletions(-)
|
||||
</pre>
|
||||
|
||||
|
||||
<p>So now I've committed the class renaming changes to the 'change_class'
|
||||
branch. If I now switch back to the 'master' branch my class name will
|
||||
revert to what it was before I switched branches. Here I can change
|
||||
revert to what it was before I switched branches. Here I can change
|
||||
something different (in this case the printed output) and at the same
|
||||
time rename the file from <code>hello.rb</code> to <code>ruby.rb</code>.
|
||||
</b>
|
||||
@ -321,12 +321,12 @@ index 2aabb6e..bf64b17 100644
|
||||
+++ b/ruby.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 "Hello World from Ruby"</span>
|
||||
end
|
||||
|
||||
|
||||
end
|
||||
<b>$ git commit -am 'added from ruby'</b>
|
||||
[master b7ae93b] added from ruby
|
||||
@ -335,9 +335,9 @@ index 2aabb6e..bf64b17 100644
|
||||
</pre>
|
||||
|
||||
<p>Now those changes are recorded in my 'master' branch. Notice that the
|
||||
class name is back to 'HelloWorld', not 'HiWorld'. Now I want to
|
||||
class name is back to 'HelloWorld', not 'HiWorld'. Now I want to
|
||||
incorporate the 'HiWorld' change so I can just merge in my 'change_class'
|
||||
branch. However, I've changed the name of the file since I branched,
|
||||
branch. However, I've changed the name of the file since I branched,
|
||||
what will Git do?</p>
|
||||
|
||||
<pre>
|
||||
@ -373,7 +373,7 @@ HiWorld.hello
|
||||
of code is edited in different branches there is no way for a computer
|
||||
to figure it out, so it's up to us. Let's see another example of changing
|
||||
the same line in two branches.
|
||||
<p>
|
||||
<p>
|
||||
|
||||
<pre>
|
||||
<b>$ git branch</b>
|
||||
@ -387,7 +387,7 @@ Switched to a new branch 'fix_readme'
|
||||
</pre>
|
||||
|
||||
<p>Now we have committed a change to one line in our README file in a
|
||||
branch. Now let's change the same line in a different way back on
|
||||
branch. Now let's change the same line in a different way back on
|
||||
our 'master' branch.</p>
|
||||
|
||||
<pre>
|
||||
@ -422,7 +422,7 @@ nearly every programming language.
|
||||
Subversion, into files when it gets a merge conflict. Now it's up to us
|
||||
to resolve them. We will do it manually here, but check out
|
||||
<a href="http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html">git mergetool</a>
|
||||
if you want Git to fire up a graphical mergetool
|
||||
if you want Git to fire up a graphical mergetool
|
||||
(like kdiff3, emerge, p4merge, etc) instead.
|
||||
</p>
|
||||
|
||||
@ -437,14 +437,14 @@ index 9103e27,69cad1a..0000000
|
||||
<span class="red">- Many Hello World Examples</span>
|
||||
<span class="red">-Hello World Lang Examples</span>
|
||||
<span class="green">++Many Hello World Lang Examples</span>
|
||||
|
||||
|
||||
This project has examples of hello world in
|
||||
</pre>
|
||||
|
||||
<p>A cool tip in doing merge conflict resolution in Git is that if you
|
||||
run <code>git diff</code>, it will show you both sides of the conflict
|
||||
and how you've resolved it as I've shown here. Now it's time to mark
|
||||
the file as resolved. In Git we do that with <code>git add</code> -
|
||||
the file as resolved. In Git we do that with <code>git add</code> -
|
||||
to tell Git the file has been resolved, you have to stage it.</p>
|
||||
|
||||
<pre>
|
||||
@ -456,7 +456,7 @@ M README
|
||||
<b>$ git commit </b>
|
||||
[master 8d585ea] Merge branch 'fix_readme'
|
||||
</pre>
|
||||
|
||||
|
||||
<p>And now we've successfully resolved our merge conflict and committed
|
||||
the result.</p>
|
||||
|
||||
@ -474,7 +474,7 @@ M README
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-log.html">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch6-1.html#commit_ranges">book</a>
|
||||
</span>
|
||||
<a name="log">git log</a>
|
||||
<span class="desc">show commit history of a branch</span>
|
||||
@ -490,8 +490,8 @@ M README
|
||||
<code>git log</code>.</p>
|
||||
|
||||
<p>To understand the log command, you have to understand what information
|
||||
is stored when you run the <code>git commit</code> command to store a
|
||||
snapshot. In addition to the manifest of files and commit message and
|
||||
is stored when you run the <code>git commit</code> command to store a
|
||||
snapshot. In addition to the manifest of files and commit message and
|
||||
information about the person who committed it, Git also stores the commit
|
||||
that you based this snapshot on. That is, if you clone a project, what was
|
||||
the snapshot that you modified to get to the snapshot that you saved? This
|
||||
@ -503,8 +503,8 @@ M README
|
||||
|
||||
<p>To see a chronological list of the parents of any branch, you can run
|
||||
<code>git log</code> when you are in that branch. For example, if we run
|
||||
<code>git log</code> in the Hello World project that we have been working
|
||||
on in this section, we'll see all the commit messages that we've done.
|
||||
<code>git log</code> in the Hello World project that we have been working
|
||||
on in this section, we'll see all the commit messages that we've done.
|
||||
|
||||
<pre>
|
||||
<b>$ git log</b>
|
||||
@ -514,7 +514,7 @@ Author: Scott Chacon <schacon@gmail.com>
|
||||
Date: Fri Jun 4 12:59:47 2010 +0200
|
||||
|
||||
Merge branch 'fix_readme'
|
||||
|
||||
|
||||
Conflicts:
|
||||
README
|
||||
|
||||
@ -539,7 +539,7 @@ Date: Fri Jun 4 12:37:05 2010 +0200
|
||||
...
|
||||
</pre>
|
||||
|
||||
<p>To see a more compact version of the same history, we can use the
|
||||
<p>To see a more compact version of the same history, we can use the
|
||||
<code>--oneline</code> option.</p>
|
||||
|
||||
<pre>
|
||||
@ -565,28 +565,28 @@ b7ae93b added from ruby
|
||||
<pre>
|
||||
<b>$ git log --oneline --graph</b>
|
||||
* 8d585ea Merge branch 'fix_readme'
|
||||
|\
|
||||
|\
|
||||
| * 3ac015d fixed readme title
|
||||
* | 3cbb6aa fixed readme title differently
|
||||
|/
|
||||
|/
|
||||
* 558151a Merge branch 'change_class'
|
||||
|\
|
||||
|\
|
||||
| * 3467b0a changed the class name
|
||||
* | b7ae93b added from ruby
|
||||
|/
|
||||
|/
|
||||
* 17f4acf first commit
|
||||
</pre>
|
||||
|
||||
<p>Now we can more clearly see when effort diverged and then was merged
|
||||
back together. This is very nice for seeing what has happened or what
|
||||
back together. This is very nice for seeing what has happened or what
|
||||
changes are applied, but
|
||||
it is also incredibly useful for managing your branches. Let's create a new
|
||||
branch, do some work in it and then switch back and do some work in our
|
||||
branch, do some work in it and then switch back and do some work in our
|
||||
master branch, then see how the <code>log</code> command can help us figure
|
||||
out what is happening on each.</p>
|
||||
|
||||
<p>First we'll create a new branch to add the Erlang programming language
|
||||
Hello World example - we want to do this in a branch so that we don't
|
||||
Hello World example - we want to do this in a branch so that we don't
|
||||
muddy up our stable branch with code that may not work for a while so we
|
||||
can cleanly switch in and out of it.</p>
|
||||
|
||||
@ -634,8 +634,8 @@ README ruby.rb
|
||||
things to do. When we come back we want to know what the 'erlang' branch
|
||||
is all about and where we've left off on the master branch. Just by looking
|
||||
at the branch name, we can't know that we made Haskell changes in there, but
|
||||
using <code>git log</code> we easily can. If you give Git a branch name,
|
||||
it will show you just the commits that are "reachable" in the history of
|
||||
using <code>git log</code> we easily can. If you give Git a branch name,
|
||||
it will show you just the commits that are "reachable" in the history of
|
||||
that branch, that is the commits that influenced the final snapshot.</p>
|
||||
|
||||
<pre>
|
||||
@ -652,15 +652,15 @@ b7ae93b added from ruby
|
||||
</pre>
|
||||
|
||||
<p>This way, it's pretty easy to see that we have Haskell code included in
|
||||
the branch (as I've highlighted). What is even cooler is that we can
|
||||
the branch (as I've highlighted). What is even cooler is that we can
|
||||
easily tell Git that we only are interested in the commits that are
|
||||
reachable in one branch that are not reachable in another, in other words
|
||||
which commits are unique to a branch in comparison to another.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In this case if we are interested in merging in the 'erlang' branch we
|
||||
want to see what commits are going to effect our snapshot when we do
|
||||
<p>
|
||||
In this case if we are interested in merging in the 'erlang' branch we
|
||||
want to see what commits are going to effect our snapshot when we do
|
||||
that merge. The way we tell Git that is by putting a <code>^</code> in
|
||||
front of the branch that we don't want to see. For instance, if we want
|
||||
to see the commits that are in the 'erlang' branch that are not in the
|
||||
@ -686,7 +686,7 @@ ab5ab4c added erlang
|
||||
at the tip of the branch. This allows you to see how the project in that
|
||||
context got to the state that it is currently in.
|
||||
</p>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@ -694,7 +694,7 @@ ab5ab4c added erlang
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-tag.html">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-6.html">book</a>
|
||||
</span>
|
||||
<a name="log">git tag</a>
|
||||
<span class="desc">tag a point in history as important</span>
|
||||
@ -723,7 +723,7 @@ ab5ab4c added erlang
|
||||
</pre>
|
||||
|
||||
<p>When you run the <code>git tag -a</code> command, Git will open your editor
|
||||
and have you write a tag message, just like you would write a commit
|
||||
and have you write a tag message, just like you would write a commit
|
||||
message.</p>
|
||||
|
||||
<p>Now, notice when we run <code>git log --decorate</code>, we can see our
|
||||
@ -733,26 +733,26 @@ ab5ab4c added erlang
|
||||
<b>$ git log --oneline --decorate --graph</b>
|
||||
* 594f90b (HEAD, <span class="hl">tag: v1.0</span>, master) reverted to old class name
|
||||
* 8d585ea Merge branch 'fix_readme'
|
||||
|\
|
||||
|\
|
||||
| * 3ac015d (fix_readme) fixed readme title
|
||||
* | 3cbb6aa fixed readme title differently
|
||||
|/
|
||||
|/
|
||||
* 558151a Merge branch 'change_class'
|
||||
|\
|
||||
|\
|
||||
| * 3467b0a changed the class name
|
||||
* | b7ae93b added from ruby
|
||||
|/
|
||||
|/
|
||||
* 17f4acf first commit
|
||||
</pre>
|
||||
|
||||
<p>If we do more commits, the tag will stay right at that commit, so we have
|
||||
that specific snapshot tagged forever and can always compare future
|
||||
that specific snapshot tagged forever and can always compare future
|
||||
snapshots to it.</p>
|
||||
|
||||
<p>We don't have to tag the commit that we're on, however. If we forgot to
|
||||
tag a commit that we released, we can retroactively tag it by running the
|
||||
same command, but with the commit SHA at the end. For example, say we had
|
||||
released commit <code>558151a</code> (several commits back) but forgot to
|
||||
released commit <code>558151a</code> (several commits back) but forgot to
|
||||
tag it at the time. We can just tag it now:</p>
|
||||
|
||||
<pre>
|
||||
@ -760,15 +760,15 @@ ab5ab4c added erlang
|
||||
<b>$ git log --oneline --decorate --graph</b>
|
||||
* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
|
||||
* 8d585ea Merge branch 'fix_readme'
|
||||
|\
|
||||
|\
|
||||
| * 3ac015d (fix_readme) fixed readme title
|
||||
* | 3cbb6aa fixed readme title differently
|
||||
|/
|
||||
|/
|
||||
* 558151a (<span class="hl">tag: v0.9</span>) Merge branch 'change_class'
|
||||
|\
|
||||
|\
|
||||
| * 3467b0a changed the class name
|
||||
* | b7ae93b added from ruby
|
||||
|/
|
||||
|/
|
||||
* 17f4acf first commit
|
||||
</pre>
|
||||
|
||||
|
@ -5,7 +5,7 @@ layout: reference
|
||||
<div class="box">
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://progit.org/book">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-3.html">book</a>
|
||||
</span>
|
||||
Inspection and Comparison
|
||||
</h2>
|
||||
@ -18,10 +18,10 @@ layout: reference
|
||||
</p>
|
||||
|
||||
<p class="nutshell">
|
||||
<b>In a nutshell</b> you can use <code>git log</code> to find specific
|
||||
<b>In a nutshell</b> you can use <code>git log</code> to find specific
|
||||
commits in your project history - by author, date, content or
|
||||
history. You can use <code>git diff</code> to compare two different points
|
||||
in your history - generally to see how two branches differ or what has
|
||||
in your history - generally to see how two branches differ or what has
|
||||
changed from one version of your software to another.
|
||||
</p>
|
||||
</div>
|
||||
@ -31,7 +31,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-log.html">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-3.html">book</a>
|
||||
</span>
|
||||
<a name="log">git log</a>
|
||||
<span class="desc">filter your commit history</span>
|
||||
@ -55,10 +55,10 @@ layout: reference
|
||||
<p>
|
||||
To filter your commit history to only the ones done by a specific author,
|
||||
you can use the <code>--author</code> option. For example, let's say we're
|
||||
looking for the commits in the Git source code done by Linus. We would
|
||||
type something like <code>git log --author=Linus</code>. The search is
|
||||
looking for the commits in the Git source code done by Linus. We would
|
||||
type something like <code>git log --author=Linus</code>. The search is
|
||||
case sensitive and also will search the email address. I'll do the
|
||||
example using the <code>-[number]</code> option, which will limit the
|
||||
example using the <code>-[number]</code> option, which will limit the
|
||||
results to the last [number] commits.
|
||||
</p>
|
||||
|
||||
@ -79,7 +79,7 @@ b532581 make "git unpack-file" a built-in
|
||||
<p>
|
||||
If you want to specify a date range that you're interested in filtering your
|
||||
commits down to, you can use a number of options - I use <code>--since</code>
|
||||
and <code>--before</code>, but you can also use <code>--until</code> and
|
||||
and <code>--before</code>, but you can also use <code>--until</code> and
|
||||
<code>--after</code>. For example, if I wanted to see all the commits in
|
||||
the Git project before 3 weeks ago but after April 18th, I could run this
|
||||
(I'm also going to use <code>--no-merges</code> to remove merge commits):
|
||||
@ -106,7 +106,7 @@ b6c8d2d Documentation/remote-helpers: Add invocation section
|
||||
<p>
|
||||
You may also want to look for commits with a certain phrase in the commit
|
||||
message. You can use <code>--grep</code> for that. Let's say I knew there
|
||||
was a commit that dealt with using the P4EDITOR environment variable and
|
||||
was a commit that dealt with using the P4EDITOR environment variable and
|
||||
I wanted to remember what that change looked like - I could find the commit
|
||||
with <code>--grep</code>.
|
||||
</p>
|
||||
@ -114,22 +114,22 @@ b6c8d2d Documentation/remote-helpers: Add invocation section
|
||||
<pre>
|
||||
<b>$ git log --grep=P4EDITOR --no-merges</b>
|
||||
<span class="yellow">commit 82cea9ffb1c4677155e3e2996d76542502611370</span>
|
||||
Author: Shawn Bohrer
|
||||
Author: Shawn Bohrer
|
||||
Date: Wed Mar 12 19:03:24 2008 -0500
|
||||
|
||||
git-p4: Use P4EDITOR environment variable when set
|
||||
|
||||
|
||||
Perforce allows you to set the P4EDITOR environment variable to your
|
||||
preferred editor for use in perforce. Since we are displaying a
|
||||
perforce changelog to the user we should use it when it is defined.
|
||||
|
||||
|
||||
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
|
||||
Signed-off-by: Simon Hausmann <simon@lst.de>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<p>
|
||||
Git will logically OR all <code>--grep</code> and <code>--author</code>
|
||||
arguments. If you want to use <code>--grep</code> and <code>--author</code>
|
||||
arguments. If you want to use <code>--grep</code> and <code>--author</code>
|
||||
to see commits that were authored by someone AND have a specific message
|
||||
content, you have to add the <code>--all-match</code> option. In these
|
||||
examples, I'm going to use the <code>--format</code> option, so we can see
|
||||
@ -146,7 +146,7 @@ da4a660 Benjamin Sergeant git-p4 fails when cloning a p4 depo.
|
||||
1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
|
||||
</pre>
|
||||
|
||||
<p>If I add a <code>--author=Hausmann</code> argument, instead of further
|
||||
<p>If I add a <code>--author=Hausmann</code> argument, instead of further
|
||||
filtering it down to the one commit by Simon, it instead will show me all
|
||||
commits by Simon OR commits with "p4 depo" in the message:</p>
|
||||
|
||||
@ -167,7 +167,7 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface.
|
||||
...
|
||||
</pre>
|
||||
|
||||
<p>However, if I add a <code>--all-match</code>, I get the results I'm
|
||||
<p>However, if I add a <code>--all-match</code>, I get the results I'm
|
||||
looking for:</p>
|
||||
|
||||
<pre>
|
||||
@ -181,11 +181,11 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface.
|
||||
</h4>
|
||||
|
||||
<p>
|
||||
What if you write really horrible commit messages? Or, what if you are
|
||||
looking for when a function was introduced, or where variables started
|
||||
to be used? You can also tell Git to look through the diff of each
|
||||
What if you write really horrible commit messages? Or, what if you are
|
||||
looking for when a function was introduced, or where variables started
|
||||
to be used? You can also tell Git to look through the diff of each
|
||||
commit for a string. For example, if we wanted to find which commits
|
||||
modified anything that looked like the function name
|
||||
modified anything that looked like the function name
|
||||
'userformat_find_requirements', we would run this: (note there is no '='
|
||||
between the '-S' and what you are searching for)
|
||||
</p>
|
||||
@ -193,21 +193,21 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface.
|
||||
<pre>
|
||||
<b>$ git log -Suserformat_find_requirements</b>
|
||||
<span class="yellow">commit 5b16360330822527eac1fa84131d185ff784c9fb</span>
|
||||
Author: Johannes Gilger
|
||||
Author: Johannes Gilger
|
||||
Date: Tue Apr 13 22:31:12 2010 +0200
|
||||
|
||||
pretty: Initialize notes if %N is used
|
||||
|
||||
|
||||
When using git log --pretty='%N' without an explicit --show-notes, git
|
||||
would segfault. This patches fixes this behaviour by loading the needed
|
||||
notes datastructures if --pretty is used and the format contains %N.
|
||||
When --pretty='%N' is used together with --no-notes, %N won't be
|
||||
expanded.
|
||||
|
||||
|
||||
This is an extension to a proposed patch by Jeff King.
|
||||
|
||||
Signed-off-by: Johannes Gilger
|
||||
Signed-off-by: Junio C Hamano
|
||||
|
||||
Signed-off-by: Johannes Gilger
|
||||
Signed-off-by: Junio C Hamano
|
||||
</pre>
|
||||
|
||||
<h4>
|
||||
@ -220,7 +220,7 @@ Date: Tue Apr 13 22:31:12 2010 +0200
|
||||
snapshot it was based off of, Git can always calculate the difference and
|
||||
show it to you as a patch. That means for any commit you can get the patch
|
||||
that commit introduced to the project. You can either do this by running
|
||||
<code>git show [SHA]</code> with a specific commit SHA, or you can run
|
||||
<code>git show [SHA]</code> with a specific commit SHA, or you can run
|
||||
<code>git log -p</code>, which tells Git to put the patch after each commit.
|
||||
It is a great way to summarize what has happened on a branch or between
|
||||
commits.
|
||||
@ -245,7 +245,7 @@ index bb86f00..192151c 100644
|
||||
puts "Hello World from Ruby"
|
||||
end
|
||||
end
|
||||
|
||||
|
||||
<span class="red">-HiWorld.hello</span>
|
||||
<span class="green">+HelloWorld.hello</span>
|
||||
|
||||
@ -263,7 +263,7 @@ index d053cc8..9103e27 100644
|
||||
<span class="red">-Hello World Examples</span>
|
||||
<span class="green">+Many Hello World Examples</span>
|
||||
======================
|
||||
|
||||
|
||||
This project has examples of hello world in
|
||||
</pre>
|
||||
|
||||
@ -310,7 +310,7 @@ Date: Fri Jun 4 12:58:53 2010 +0200
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-diff.html">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch5-3.html#determining_what_is_introduced">book</a>
|
||||
</span>
|
||||
<a name="diff">git diff</a>
|
||||
<span class="desc"></span>
|
||||
@ -318,15 +318,15 @@ Date: Fri Jun 4 12:58:53 2010 +0200
|
||||
|
||||
<div class="block">
|
||||
|
||||
<p>Finally, to see the absolute changes between any two commit snapshots,
|
||||
<p>Finally, to see the absolute changes between any two commit snapshots,
|
||||
you can use the <code>git diff</code> command. This is largely used in two
|
||||
main situations - seeing how two branches differ from one another and
|
||||
seeing what has changed since a release or some other older point in
|
||||
main situations - seeing how two branches differ from one another and
|
||||
seeing what has changed since a release or some other older point in
|
||||
history. Let's look at both of these situations.</p>
|
||||
|
||||
<p>To see what has changed since the last release, you can simply run
|
||||
<code>git diff [version]</code> (or whatever you tagged the release).
|
||||
For example, if we want to see what has changed in our project since
|
||||
<code>git diff [version]</code> (or whatever you tagged the release).
|
||||
For example, if we want to see what has changed in our project since
|
||||
the v0.9 release, we can run <code>git diff v0.9</code>.
|
||||
</p>
|
||||
|
||||
@ -340,7 +340,7 @@ index d053cc8..d4173d5 100644
|
||||
<span class="red">-Hello World Examples</span>
|
||||
<span class="green">+Many Hello World Lang Examples</span>
|
||||
======================
|
||||
|
||||
|
||||
This project has examples of hello world in
|
||||
<span class="umber">diff --git a/ruby.rb b/ruby.rb
|
||||
index bb86f00..192151c 100644
|
||||
@ -353,12 +353,12 @@ index bb86f00..192151c 100644
|
||||
puts "Hello World from Ruby"
|
||||
end
|
||||
end
|
||||
|
||||
|
||||
<span class="red">-HiWorld.hello</span>
|
||||
<span class="green">+HelloWorld.hello</span>
|
||||
</pre>
|
||||
|
||||
<p>Just like <code>git log</code>, you can use the <code>--stat</code>
|
||||
<p>Just like <code>git log</code>, you can use the <code>--stat</code>
|
||||
option with it.</p>
|
||||
|
||||
<pre>
|
||||
@ -373,7 +373,7 @@ index bb86f00..192151c 100644
|
||||
exactly what you are asking - it will basically give you a patch file that
|
||||
would turn the snapshot at the tip of branchA into the snapshot at the tip
|
||||
of branchB. This means if the two branches have diverged - gone in different
|
||||
directions - it will remove all the work that was introduced into branchA
|
||||
directions - it will remove all the work that was introduced into branchA
|
||||
and then add everything that was introduced into branchB. This is probably
|
||||
not what you want - you want the changes added to branchB that are not in
|
||||
branchA, so you really want the difference between where the two branches
|
||||
@ -384,7 +384,7 @@ index bb86f00..192151c 100644
|
||||
* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
|
||||
| * 1834130 (erlang) added haskell
|
||||
| * ab5ab4c added erlang
|
||||
|/
|
||||
|/
|
||||
* 8d585ea Merge branch 'fix_readme'
|
||||
...
|
||||
</pre>
|
||||
@ -403,7 +403,7 @@ index bb86f00..192151c 100644
|
||||
|
||||
<p>You see that it adds the erlang and haskell files, which is what we did
|
||||
in that branch, but then the output also reverts the changes to the ruby file
|
||||
that we did in the master branch. What we really want to see is just the
|
||||
that we did in the master branch. What we really want to see is just the
|
||||
changes that happened in the "erlang" branch (adding the two files). We can
|
||||
get the desired result by doing the diff from the common commit they diverged
|
||||
from:</p>
|
||||
@ -416,9 +416,9 @@ index bb86f00..192151c 100644
|
||||
</pre>
|
||||
|
||||
<p>That's what we're looking for, but we don't want to have to figure out
|
||||
what commit the two branches diverged from every time. Luckily, Git has a
|
||||
what commit the two branches diverged from every time. Luckily, Git has a
|
||||
shortcut for this. If you run <code>git diff master...erlang</code> (with three dots in between the branch names), Git will automatically figure out
|
||||
what the common commit (otherwise known as the "merge base") of the two
|
||||
what the common commit (otherwise known as the "merge base") of the two
|
||||
commit is and do the diff off of that.</p>
|
||||
|
||||
<pre>
|
||||
@ -437,7 +437,7 @@ index bb86f00..192151c 100644
|
||||
the triple-dot syntax, because it will almost always give you what you want.
|
||||
</p>
|
||||
|
||||
<p>As a bit of an aside, you can also have git manually calculate the
|
||||
<p>As a bit of an aside, you can also have git manually calculate the
|
||||
merge-base (first common ancestor commit) of any two commits would be with
|
||||
the <code>git merge-base</code> command:</p>
|
||||
|
||||
@ -462,13 +462,13 @@ index bb86f00..192151c 100644
|
||||
<p class="nutshell">
|
||||
<b>In a nutshell</b> you can use <code>git diff</code> to see how a project
|
||||
has changed since a known point in the past or to see what unique work is
|
||||
in one branch since it diverged from another. Always use
|
||||
<code>git diff branchA...branchB</code> to inspect branchB relative to
|
||||
in one branch since it diverged from another. Always use
|
||||
<code>git diff branchA...branchB</code> to inspect branchB relative to
|
||||
branchA to make things easier.
|
||||
</p>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<p>And that's it! For more information, try reading the
|
||||
<p>And that's it! For more information, try reading the
|
||||
<a href="http://progit.org">Pro Git book</a>.</p>
|
||||
|
@ -5,15 +5,15 @@ layout: reference
|
||||
<div class="box">
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://progit.org/book">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-5.html">book</a>
|
||||
</span>
|
||||
Sharing and Updating Projects
|
||||
</h2>
|
||||
<div class="block">
|
||||
<p>
|
||||
Git doesn't have a central server like Subversion. All of the commands
|
||||
so far have been done locally, just updating a local database.
|
||||
To collaborate with other developers in Git, you have to put all that
|
||||
so far have been done locally, just updating a local database.
|
||||
To collaborate with other developers in Git, you have to put all that
|
||||
data on a server that the other developers have access to. The way Git
|
||||
does this is to syncronize your data with another repository. There
|
||||
is no real difference between a server and a client - a Git repository
|
||||
@ -27,14 +27,14 @@ layout: reference
|
||||
</p>
|
||||
|
||||
<p>You can do this any time you are online, it does not have to correspond
|
||||
with a <code>commit</code> or anything else. Generally you will do a
|
||||
with a <code>commit</code> or anything else. Generally you will do a
|
||||
number of commits locally, then fetch data from the online shared repository
|
||||
you cloned the project from to get up to date, merge any new work into the
|
||||
stuff you did, then push your changes back up.</p>
|
||||
|
||||
<p class="nutshell">
|
||||
<b>In a nutshell</b> you can update your project with <code>git fetch</code>
|
||||
and share your changes with <code>git push</code>. You can manage your
|
||||
and share your changes with <code>git push</code>. You can manage your
|
||||
remote repositories with <code>git remote</code>.
|
||||
</p>
|
||||
</div>
|
||||
@ -44,7 +44,7 @@ layout: reference
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-remote.html">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-5.html#showing_your_remotes">book</a>
|
||||
</span>
|
||||
<a name="push">git remote</a>
|
||||
<span class="desc">list, add and delete remote repository aliases</span>
|
||||
@ -59,8 +59,8 @@ layout: reference
|
||||
and others that you can write to as well.</p>
|
||||
|
||||
<p>So that you don't have to use the full URL of a remote repository every
|
||||
time you want to syncronize with it, Git stores an alias or nickname for
|
||||
each remote repository URL you are interested in. You use the
|
||||
time you want to syncronize with it, Git stores an alias or nickname for
|
||||
each remote repository URL you are interested in. You use the
|
||||
<code>git remote</code> command to manage this list of remote repos that
|
||||
you care about.</p>
|
||||
|
||||
@ -70,10 +70,10 @@ layout: reference
|
||||
</h4>
|
||||
|
||||
<p>Without any arguments, Git will simply show you the remote repository
|
||||
aliases that it has stored. By default, if you cloned the project (as
|
||||
aliases that it has stored. By default, if you cloned the project (as
|
||||
opposed to creating a new one locally), Git will automatically add the
|
||||
URL of the repository that you cloned from under the name 'origin'. If
|
||||
you run the command with the <code>-v</code> option, you can see the
|
||||
you run the command with the <code>-v</code> option, you can see the
|
||||
actual URL for each alias.</p>
|
||||
|
||||
<pre>
|
||||
@ -94,12 +94,12 @@ origin git@github.com:schacon/git-reference.git (push)
|
||||
</h4>
|
||||
|
||||
<p>If you want to share a locally created repository, or you want to take
|
||||
contributions from someone elses repository - if you want to interact in
|
||||
contributions from someone elses repository - if you want to interact in
|
||||
any way with a new repository, it's generally easiest to add it as a remote.
|
||||
You do that by running <code>git remote add [alias] [url]</code>. That
|
||||
adds <code>[url]</code> under a local remote named <code>[alias]</code>.</p>
|
||||
|
||||
<p>For example, if we want to share our Hello World program with the world,
|
||||
<p>For example, if we want to share our Hello World program with the world,
|
||||
we can create a new repository on a server (I'll use GitHub as an example),
|
||||
which should give you a URL, in this case "git@github.com:schacon/hw.git".
|
||||
To add that to our project so we can push to it and fetch updates from it
|
||||
@ -114,9 +114,9 @@ github git@github.com:schacon/hw.git (push)
|
||||
</pre>
|
||||
|
||||
<p>Like the branch naming, remote alias names are arbitrary - just as 'master'
|
||||
has no special meaning but is widely used because <code>git init</code>
|
||||
sets it up by default, 'origin' is often used as a remote name because
|
||||
<code>git clone</code> sets it up by default as the cloned-from URL. In
|
||||
has no special meaning but is widely used because <code>git init</code>
|
||||
sets it up by default, 'origin' is often used as a remote name because
|
||||
<code>git clone</code> sets it up by default as the cloned-from URL. In
|
||||
this case I've decided to name my remote 'github', but I could have really
|
||||
named it just about anything.
|
||||
</p>
|
||||
@ -147,9 +147,9 @@ github git@github.com:schacon/hw.git (push)
|
||||
</pre>
|
||||
|
||||
<p class="nutshell">
|
||||
<b>In a nutshell</b> with <code>git remote</code> you can list our
|
||||
<b>In a nutshell</b> with <code>git remote</code> you can list our
|
||||
remote repositories and whatever URL
|
||||
that repository is using. You can use <code>git remote add</code> to
|
||||
that repository is using. You can use <code>git remote add</code> to
|
||||
add new remotes and <code>git remote rm</code> to delete existing ones.
|
||||
</p>
|
||||
|
||||
@ -160,7 +160,7 @@ github git@github.com:schacon/hw.git (push)
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-5.html#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>
|
||||
@ -181,9 +181,9 @@ github git@github.com:schacon/hw.git (push)
|
||||
|
||||
<p>Git has two commands to update itself from a remote repository.
|
||||
<code>git fetch</code> will syncronize you with another repo, pulling down any data
|
||||
that you do not have locally and giving you bookmarks to where each branch on
|
||||
that you do not have locally and giving you bookmarks to where each branch on
|
||||
that remote was when you syncronized. These are called "remote branches" and are
|
||||
identical to local branches except that Git will not allow you to check them out -
|
||||
identical to local branches except that Git will not allow you to check them out -
|
||||
however, you can merge from them, diff them to other branches, run history logs on
|
||||
them, etc. You do all of that stuff locally after you syncronize.
|
||||
</p>
|
||||
@ -201,7 +201,7 @@ github git@github.com:schacon/hw.git (push)
|
||||
<p>Assuming you have a remote all set up and you want to pull in updates, you
|
||||
would first run <code>git fetch [alias]</code> to tell Git to fetch down all the
|
||||
data it has that you do not, then you would run <code>git merge [alias]/[branch]</code>
|
||||
to merge into your current branch anything new you see on the server
|
||||
to merge into your current branch anything new you see on the server
|
||||
(like if someone else has pushed in the meantime). So, if I were working on my
|
||||
Hello World project with several other people and I wanted to bring in any changes
|
||||
that had been pushed since I last connected, I would do something like this:</p>
|
||||
@ -216,7 +216,7 @@ Resolving deltas: 100% (1526/1526), completed with 387 local objects.
|
||||
From github.com:schacon/hw
|
||||
8e29b09..c7c5a10 master -> github/master
|
||||
0709fdc..d4ccf73 c-langs -> github/c-langs
|
||||
6684f82..ae06d2b java -> github/java
|
||||
6684f82..ae06d2b java -> github/java
|
||||
* [new branch] ada -> github/ada
|
||||
* [new branch] lisp -> github/lisp
|
||||
</pre>
|
||||
@ -228,11 +228,11 @@ From github.com:schacon/hw
|
||||
into 'master'.
|
||||
</p>
|
||||
|
||||
<p>You can see the mapping that Git makes. The 'master' branch on the remote
|
||||
<p>You can see the mapping that Git makes. The 'master' branch on the remote
|
||||
repository becomes a branch named 'github/master' locally. That way now I can
|
||||
merge the 'master' branch on that remote into my local 'master' branch by running
|
||||
<code>git merge github/master</code>. Or, I can see what new commits are on that
|
||||
branch by running <code>git log github/master ^master</code>. If your remote
|
||||
branch by running <code>git log github/master ^master</code>. If your remote
|
||||
is named 'origin' it would be <code>origin/master</code> instead. Almost any
|
||||
command you would run using local branches you can use remote branches with too.
|
||||
</p>
|
||||
@ -242,8 +242,8 @@ From github.com:schacon/hw
|
||||
with all of your remotes by running <code>git fetch --all</code>.
|
||||
|
||||
<p class="nutshell">
|
||||
<b>In a nutshell</b> you run <code>git fetch [alias]</code> to syncronize your
|
||||
repository with a remote repository, fetching all the data it has that you do
|
||||
<b>In a nutshell</b> you run <code>git fetch [alias]</code> to syncronize your
|
||||
repository with a remote repository, fetching all the data it has that you do
|
||||
not into branch references locally for merging and whatnot.
|
||||
</p>
|
||||
|
||||
@ -255,7 +255,7 @@ From github.com:schacon/hw
|
||||
<h2>
|
||||
<span class="docs">
|
||||
<a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-push.html">docs</a>
|
||||
<a target="new" href="http://progit.org/book/">book</a>
|
||||
<a target="new" href="http://progit.org/book/ch2-5.html#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>
|
||||
@ -263,7 +263,7 @@ From github.com:schacon/hw
|
||||
|
||||
<div class="block">
|
||||
<p>To share the cool commits you've done with others, you need to push your
|
||||
changes to the remote repository. To do this, you run
|
||||
changes to the remote repository. To do this, you run
|
||||
<code>git push [alias] [branch]</code> which will attempt to make your [branch]
|
||||
the new [branch] on the [alias] remote. Let's try it by initially pushing
|
||||
our 'master' branch to the new 'github' remote we created earlier.</p>
|
||||
@ -304,15 +304,15 @@ To git@github.com:schacon/hw.git
|
||||
|
||||
<p>The last major issue you run into with pushing to remote branches is the
|
||||
case of someone pushing in the meantime. If you and another developer clone
|
||||
at the same time, you both do commits, then she pushes and then you try to
|
||||
at the same time, you both do commits, then she pushes and then you try to
|
||||
push, Git will by default not allow you to overwrite her changes. Instead,
|
||||
it basically runs <code>git log</code> on the branch you're trying to push and
|
||||
makes sure it can see the current tip of the servers branch in your pushes
|
||||
history. If it can't see what is on the server in your history, it concludes
|
||||
that you are out of date and will reject your push. You will rightly have to
|
||||
fetch, merge then push again - which makes sure you take her changes into
|
||||
fetch, merge then push again - which makes sure you take her changes into
|
||||
account.</p>
|
||||
|
||||
|
||||
<p>This is what happens when you try to push a branch to a remote branch
|
||||
that has been updated in the meantime:</p>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user