From 7057ccb078b6a2cc2370416a11251d1e7a91d92f Mon Sep 17 00:00:00 2001 From: Scott Chacon Date: Thu, 10 Jun 2010 14:24:14 -0700 Subject: [PATCH] updated all the book urls --- branching/index.html | 140 +++++++++++++++++++++---------------------- inspect/index.html | 94 ++++++++++++++--------------- remotes/index.html | 62 +++++++++---------- 3 files changed, 148 insertions(+), 148 deletions(-) diff --git a/branching/index.html b/branching/index.html index eddbb10..abf3f3a 100644 --- a/branching/index.html +++ b/branching/index.html @@ -5,7 +5,7 @@ layout: reference

- book + book Branching and Merging

@@ -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 contexts 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.

- In a nutshell you can create a branch with + In a nutshell you can create a branch with git branch (branchname), switch into that context with git checkout (branchname), 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 git merge. 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.

@@ -39,7 +39,7 @@ layout: reference

docs   - book + book git branch list, create and manage working contexts @@ -50,7 +50,7 @@ layout: reference

docs   - book + book git checkout switch to a new branch context @@ -69,10 +69,10 @@ layout: reference list your available branches

-

Without arguments, git branch will list out the local +

Without arguments, git branch 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 - coloring turned on, + have a star next to it and if you have + coloring turned on, will show the current branch in green.

@@ -105,7 +105,7 @@ $ git branch

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 git checkout (branch) to switch the @@ -188,20 +188,20 @@ README hello.rb more.txt test.txt contexts we can switch between.

- 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.

- +

git branch -d (branchname) delete a branch

-

If we want to delete a branch (such as the 'testing' branch in the - previous example, since there is no unique work on it), +

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 git branch -d (branch) to remove it. 

@@ -215,8 +215,8 @@ Deleted branch testing (was 78b2670).

- In a nutshell you use git branch to list your - current branches, create new branches and delete unnecessary or + In a nutshell you use git branch to list your + current branches, create new branches and delete unnecessary or already merged branches.

@@ -227,20 +227,20 @@ Deleted branch testing (was 78b2670).

docs   - book + book git merge merge a branch context into your current one

-

Once you have work isolated in a branch, you will eventually want to +

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 git merge command. Let's take as a + current branch with the git merge 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.

@@ -266,7 +266,7 @@ Fast-forward more complex merges -

Of course, this doesn't just work for simple file additions and +

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 -

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 +

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'.

@@ -301,10 +301,10 @@ class HiWorld
 [change_class 3467b0a] changed the class name
  1 files changed, 2 insertions(+), 4 deletions(-)
- +

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 hello.rb to ruby.rb. @@ -321,12 +321,12 @@ index 2aabb6e..bf64b17 100644 +++ b/ruby.rb @@ -1,7 +1,7 @@ class HelloWorld - + def self.hello - puts "Hello World" + puts "Hello World from Ruby" end - + end $ git commit -am 'added from ruby' [master b7ae93b] added from ruby @@ -335,9 +335,9 @@ index 2aabb6e..bf64b17 100644

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?

@@ -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.
-    
 
+    

 
 
 $ git branch
@@ -387,7 +387,7 @@ Switched to a new branch 'fix_readme'
 

 
     
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.

 
 
@@ -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
       git mergetool
-      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.
     

 
@@ -437,14 +437,14 @@ index 9103e27,69cad1a..0000000
 - Many Hello World Examples
  -Hello World Lang Examples
 ++Many Hello World Lang Examples
-  
+
   This project has examples of hello world in
 

 
     
A cool tip in doing merge conflict resolution in Git is that if you
     run git diff, 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 git add - 
+    the file as resolved.  In Git we do that with git add -
     to tell Git the file has been resolved, you have to stage it.

 
 
@@ -456,7 +456,7 @@ M  README
 $ git commit 
 [master 8d585ea] Merge branch 'fix_readme'
 

-    
+
     
And now we've successfully resolved our merge conflict and committed
     the result.

 
@@ -474,7 +474,7 @@ M  README
   

     
       docs  
-      book
+      book
     
     git log
     show commit history of a branch
@@ -490,8 +490,8 @@ M  README
     git log.

 
     
To understand the log command, you have to understand what information
-    is stored when you run the git commit command to store a 
-    snapshot.  In addition to the manifest of files and commit message and 
+    is stored when you run the git commit 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
 
     
To see a chronological list of the parents of any branch, you can run
     git log when you are in that branch.  For example, if we run
-    git log 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. 
+    git log 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.
 
 
 $ git log
@@ -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
 ...
 

 
-    
To see a more compact version of the same history, we can use the 
+    
To see a more compact version of the same history, we can use the
     --oneline option.

 
 
@@ -565,28 +565,28 @@ b7ae93b added from ruby
 
 $ git log --oneline --graph
 *   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
 

 
     
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 log command can help us figure
     out what is happening on each.

 
     
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.

 
@@ -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 git log 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 git log 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.

 
 
@@ -652,15 +652,15 @@ b7ae93b added from ruby
 

 
     
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.
     

 
-    
 
-      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 
+    

+      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 ^ 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.
     

-    
+
@@ -694,7 +694,7 @@ ab5ab4c added erlang

docs   - book + book git tag tag a point in history as important @@ -723,7 +723,7 @@ ab5ab4c added erlang

When you run the git tag -a 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.

Now, notice when we run git log --decorate, we can see our @@ -733,26 +733,26 @@ ab5ab4c added erlang $ git log --oneline --decorate --graph * 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 Merge branch 'change_class' -|\ +|\ | * 3467b0a changed the class name * | b7ae93b added from ruby -|/ +|/ * 17f4acf first commit

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.

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 558151a (several commits back) but forgot to + released commit 558151a (several commits back) but forgot to tag it at the time. We can just tag it now:

@@ -760,15 +760,15 @@ ab5ab4c added erlang
 $ git log --oneline --decorate --graph
 * 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 (tag: v0.9) Merge branch 'change_class'
-|\  
+|\
 | * 3467b0a changed the class name
 * | b7ae93b added from ruby
-|/  
+|/
 * 17f4acf first commit
diff --git a/inspect/index.html b/inspect/index.html index 654220d..6adcee4 100644 --- a/inspect/index.html +++ b/inspect/index.html @@ -5,7 +5,7 @@ layout: reference

- book + book Inspection and Comparison

@@ -18,10 +18,10 @@ layout: reference

- In a nutshell you can use git log to find specific + In a nutshell you can use git log to find specific commits in your project history - by author, date, content or history. You can use git diff 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.

@@ -31,7 +31,7 @@ layout: reference

docs   - book + book git log filter your commit history @@ -55,10 +55,10 @@ layout: reference

To filter your commit history to only the ones done by a specific author, you can use the --author 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 git log --author=Linus. The search is + looking for the commits in the Git source code done by Linus. We would + type something like git log --author=Linus. The search is case sensitive and also will search the email address. I'll do the - example using the -[number] option, which will limit the + example using the -[number] option, which will limit the results to the last [number] commits.

@@ -79,7 +79,7 @@ b532581 make "git unpack-file" a built-in

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 --since - and --before, but you can also use --until and + and --before, but you can also use --until and --after. 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 --no-merges to remove merge commits): @@ -106,7 +106,7 @@ b6c8d2d Documentation/remote-helpers: Add invocation section

You may also want to look for commits with a certain phrase in the commit message. You can use --grep 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 --grep.

@@ -114,22 +114,22 @@ b6c8d2d Documentation/remote-helpers: Add invocation section 
 $ git log --grep=P4EDITOR --no-merges
 commit 82cea9ffb1c4677155e3e2996d76542502611370
-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 
     Signed-off-by: Simon Hausmann
-

+

Git will logically OR all --grep and --author - arguments. If you want to use --grep and --author + arguments. If you want to use --grep and --author to see commits that were authored by someone AND have a specific message content, you have to add the --all-match option. In these examples, I'm going to use the --format 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 -

If I add a --author=Hausmann argument, instead of further +

If I add a --author=Hausmann 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:

@@ -167,7 +167,7 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface. ... -

However, if I add a --all-match, I get the results I'm +

However, if I add a --all-match, I get the results I'm looking for:

@@ -181,11 +181,11 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface.

- 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)

@@ -193,21 +193,21 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface. 
 $ git log -Suserformat_find_requirements
 commit 5b16360330822527eac1fa84131d185ff784c9fb
-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

@@ -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 - git show [SHA] with a specific commit SHA, or you can run + git show [SHA] with a specific commit SHA, or you can run git log -p, 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 - + -HiWorld.hello +HelloWorld.hello @@ -263,7 +263,7 @@ index d053cc8..9103e27 100644 -Hello World Examples +Many Hello World Examples ====================== - + This project has examples of hello world in @@ -310,7 +310,7 @@ Date: Fri Jun 4 12:58:53 2010 +0200

docs   - book + book git diff @@ -318,15 +318,15 @@ Date: Fri Jun 4 12:58:53 2010 +0200
-

Finally, to see the absolute changes between any two commit snapshots, +

Finally, to see the absolute changes between any two commit snapshots, you can use the git diff 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.

To see what has changed since the last release, you can simply run - git diff [version] (or whatever you tagged the release). - For example, if we want to see what has changed in our project since + git diff [version] (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 git diff v0.9.

@@ -340,7 +340,7 @@ index d053cc8..d4173d5 100644 -Hello World Examples +Many Hello World Lang Examples ====================== - + This project has examples of hello world in 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 - + -HiWorld.hello +HelloWorld.hello -

Just like git log, you can use the --stat +

Just like git log, you can use the --stat option with it.

@@ -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'
 ...
@@ -403,7 +403,7 @@ index bb86f00..192151c 100644

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:

@@ -416,9 +416,9 @@ index bb86f00..192151c 100644

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 git diff master...erlang (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.

@@ -437,7 +437,7 @@ index bb86f00..192151c 100644
     the triple-dot syntax, because it will almost always give you what you want.
     

 
-    
As a bit of an aside, you can also have git manually calculate the 
+    
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 git merge-base command:

 
@@ -462,13 +462,13 @@ index bb86f00..192151c 100644
     

     In a nutshell you can use git diff 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 
-    git diff branchA...branchB to inspect branchB relative to 
+    in one branch since it diverged from another.  Always use
+    git diff branchA...branchB to inspect branchB relative to
     branchA to make things easier.
-

And that's it! For more information, try reading the +

And that's it! For more information, try reading the Pro Git book.

diff --git a/remotes/index.html b/remotes/index.html index 39709bd..8e2d7f1 100644 --- a/remotes/index.html +++ b/remotes/index.html @@ -5,15 +5,15 @@ layout: reference

- book + book Sharing and Updating Projects

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

You can do this any time you are online, it does not have to correspond - with a commit or anything else. Generally you will do a + with a commit 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.

In a nutshell you can update your project with git fetch - and share your changes with git push. You can manage your + and share your changes with git push. You can manage your remote repositories with git remote.

@@ -44,7 +44,7 @@ layout: reference

docs   - book + book git remote list, add and delete remote repository aliases @@ -59,8 +59,8 @@ layout: reference and others that you can write to as well.

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 git remote command to manage this list of remote repos that you care about.

@@ -70,10 +70,10 @@ layout: reference

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 -v option, you can see the + you run the command with the -v option, you can see the actual URL for each alias.

@@ -94,12 +94,12 @@ origin	git@github.com:schacon/git-reference.git (push)

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 git remote add [alias] [url]. That adds [url] under a local remote named [alias].

-

For example, if we want to share our Hello World program with the world, +

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)

Like the branch naming, remote alias names are arbitrary - just as 'master' - has no special meaning but is widely used because git init - sets it up by default, 'origin' is often used as a remote name because - git clone sets it up by default as the cloned-from URL. In + has no special meaning but is widely used because git init + sets it up by default, 'origin' is often used as a remote name because + git clone 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.

@@ -147,9 +147,9 @@ github git@github.com:schacon/hw.git (push)

- In a nutshell with git remote you can list our + In a nutshell with git remote you can list our remote repositories and whatever URL - that repository is using. You can use git remote add to + that repository is using. You can use git remote add to add new remotes and git remote rm to delete existing ones.

@@ -160,7 +160,7 @@ github git@github.com:schacon/hw.git (push)

docs   - book + book git fetch download new branches and data from a remote repository @@ -181,9 +181,9 @@ github git@github.com:schacon/hw.git (push)

Git has two commands to update itself from a remote repository. git fetch 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.

@@ -201,7 +201,7 @@ github git@github.com:schacon/hw.git (push)

Assuming you have a remote all set up and you want to pull in updates, you would first run git fetch [alias] to tell Git to fetch down all the data it has that you do not, then you would run git merge [alias]/[branch] - 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:

@@ -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 @@ -228,11 +228,11 @@ From github.com:schacon/hw into 'master'.

-

You can see the mapping that Git makes. The 'master' branch on the remote +

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 git merge github/master. Or, I can see what new commits are on that - branch by running git log github/master ^master. If your remote + branch by running git log github/master ^master. If your remote is named 'origin' it would be origin/master instead. Almost any command you would run using local branches you can use remote branches with too.

@@ -242,8 +242,8 @@ From github.com:schacon/hw with all of your remotes by running git fetch --all.

- In a nutshell you run git fetch [alias] to syncronize your - repository with a remote repository, fetching all the data it has that you do + In a nutshell you run git fetch [alias] 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.

@@ -255,7 +255,7 @@ From github.com:schacon/hw

docs   - book + book git push push your new branches and data to a remote repository @@ -263,7 +263,7 @@ From github.com:schacon/hw

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 git push [alias] [branch] 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.

@@ -304,15 +304,15 @@ To git@github.com:schacon/hw.git

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 git log 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.

- +

This is what happens when you try to push a branch to a remote branch that has been updated in the meantime: