Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

episode desc to match rug body; too many nows; pro git link moved

- episode description mentions syncing that is not part of page
  and to be better covered in remotes
- more definite sentences, cutting down on run-ons in order
  to be clearer in delivery
- counted a lot of "now" and felt like a car needing a new
  air filter
- decrease chances of time travel by only being able to
  refer to things from the past
- pro git book has moved its site, link for chapter 2
  • Loading branch information...
commit 77ed53fe9794e072df26fcf155eb6c360550d91f 1 parent 3145a1f
@randomecho randomecho authored
Showing with 42 additions and 39 deletions.
  1. +1 −1  episodes.yaml
  2. +17 −15 p/normal.html
  3. +24 −23 pages/normal.markdown
View
2  episodes.yaml
@@ -17,7 +17,7 @@ episodes:
- name: Normal Workflow
page: normal
- desc: Syncronize with a remote repository, make changes,
+ desc: Make and view changes made,
then stage and commit them.
- name: Branching and Merging
View
32 p/normal.html
@@ -38,13 +38,13 @@
<div class="span-21" id="welcome">
<h1>Normal Workflow</h1>
- <p>Syncronize with a remote repository, make changes, then stage and commit them.</p>
+ <p>Make and view changes made, then stage and commit them.</p>
</div>
<div class="content">
<div class="span-21"><hr/><p>So you have a Git repository and everything is all setup. What now?</p>
-<p>Generally, it is not going to be much different than working with any other source control system, the only real difference should be the staging process. The workflow will generally go something like this:</p>
+<p>Generally, it is not going to be much different than working with any other source control system. The only real difference should be the staging process. The workflow will generally go something like this:</p>
<ul>
<li>modify files</li>
@@ -58,7 +58,7 @@
<li>rinse, repeat</li>
</ul>
-<p>That is the most complex case - if you&#8217;re not collaborating with anyone and so have no upstream repository to push to, and you want to ignore the staging area, it can be as simple as:</p>
+<p>That is the most complex case. If you&#8217;re not collaborating with anyone and so have no upstream repository to push to, and you want to ignore the staging area, it can be as simple as:</p>
<ul>
<li>modify files</li>
@@ -77,7 +77,9 @@ <h3 id='the_simple_case'>the simple case</h3>
<pre><code>$ git clone git://github.com/schacon/simplegit.git
$ cd simplegit</code></pre>
-<p>For this first example we&#8217;ll modify the README file to add ourselves as an author on the project. So we simply edit the file. Now we want to commit that change, so we run the &#8216;git commit -a&#8217; command. The &#8216;-a&#8217; tells Git to stage all modified files and then commit - we&#8217;ll cover the &#8216;staging area&#8217; next, but for now just running &#8216;git commit -a&#8217; will act something like the &#8216;commit&#8217; command in SVN.</p>
+<p>For this first example we&#8217;ll modify the README file to add ourselves as an author on the project.</p>
+
+<p>First, we simply edit the file. Now we want to commit that change, so we run the &#8216;git commit -a&#8217; command. The &#8216;-a&#8217; tells Git to stage all modified files and then commit - we&#8217;ll cover the &#8216;staging area&#8217; next, but for now just running &#8216;git commit -a&#8217; will act something like the &#8216;commit&#8217; command in SVN.</p>
<p>A prompt for a commit message will open in our editor (the $EDITOR environment variable or &#8216;core.editor&#8217; git config variable - by default it uses &#8216;vim&#8217;) that looks like this:</p>
@@ -100,13 +102,13 @@ <h3 id='the_simple_case'>the simple case</h3>
[master]: created 5896d4d: &quot;added myself to the README as an author&quot;
1 files changed, 2 insertions(+), 1 deletions(-)</code></pre>
-<p>Git will show us the commit message we typed and some statistics about what changes were introduced in that commit. It will also give us a checksum of the commit, &#8216;5896d4d&#8217;, that we can use to refer to this exact commit at any other time.</p>
+<p>Git will show us the commit message we typed and some statistics about what changes were introduced in that commit. It will also give us a checksum of the commit, &#8216;5896d4d&#8217;, that we can use to refer to this exact commit later on.</p>
<p>That&#8217;s it - that&#8217;s the simple case. Edit files, &#8216;git commit -a&#8217;, repeat.</p>
<h3 id='using_the_staging_area'>using the staging area</h3>
-<p>Now we&#8217;re going to cover how to more carefully craft commits using what Git calles the &#8216;staging area&#8217;. For this example, let&#8217;s say that we have updated your files like we did in the previous section. However, now let&#8217;s imagine that we wanted to commit the changes we&#8217;ve made as two separate commits rather than one. We can see what has been changed in our working directory by using the &#8216;git status&#8217; command.</p>
+<p>Now we&#8217;re going to cover how to more carefully craft commits using what Git calls the &#8216;staging area&#8217;. For this example, let&#8217;s say that we have updated your files like we did in the previous section. However, let&#8217;s now imagine that we wanted to commit the changes we&#8217;ve made as two separate commits rather than one. We can see what has been changed in our working directory by using the &#8216;git status&#8217; command.</p>
<pre><code>$ git status
# On branch master
@@ -123,7 +125,7 @@ <h3 id='using_the_staging_area'>using the staging area</h3>
<p><img alt='Git Staging Workflow' src='../images/staging.png' /></p>
-<p>So, let&#8217;s stage the files. Git uses the &#8216;git add&#8217; command both to begin tracking files and also to stage changes to them. So let&#8217;s stage the changes in just the README file, then take a look at our status again.</p>
+<p>So, let&#8217;s stage the files. Git uses the &#8216;git add&#8217; command both to begin tracking files and also to stage changes to them. We&#8217;ll stage the changes in just the README file, then take a look at our status again.</p>
<pre><code>$ git add README
$ git status
@@ -139,13 +141,13 @@ <h3 id='using_the_staging_area'>using the staging area</h3>
#
# modified: lib/simplegit.rb</code></pre>
-<p>Now the &#8216;lib/simplegit.rb&#8217; file is still unstaged, but the README file is now under the &#8216;Changes to be committed&#8217; section - it is <strong>staged</strong>. Now if we run the commit command (without the -a, which automatically stages everything), only the changes to that file will go into the commit - the simplegit.rb file will remain unstaged. In this instance, we&#8217;ll use the &#8216;-m&#8217; option to &#8216;git commit&#8217; to specify the commit message on the command line.</p>
+<p>The &#8216;lib/simplegit.rb&#8217; file is still unstaged, but the README file is now under the &#8216;Changes to be committed&#8217; section - it is <strong>staged</strong>. If we run the commit command (without the -a, which automatically stages everything), only the changes to that file will go into the commit - the &#8216;simplegit.rb&#8217; file will remain unstaged. In this instance, we&#8217;ll use the &#8216;-m&#8217; option with &#8216;git commit&#8217; to specify the commit message on the command line.</p>
<pre><code>$ git commit -m &#39;updated the README&#39;
[master]: created 14bb3c6: &quot;updated the README&quot;
1 files changed, 1 insertions(+), 2 deletions(-)</code></pre>
-<p>Now if we run &#8216;git status&#8217; again, we can see that the staged file is now committed and all we have left is the unstaged &#8216;simplegit.rb&#8217; file.</p>
+<p>If we run &#8216;git status&#8217; again, we can see that the staged file is now committed and all we have left is the unstaged &#8216;simplegit.rb&#8217; file.</p>
<pre><code>$ git status
# On branch master
@@ -158,7 +160,7 @@ <h3 id='using_the_staging_area'>using the staging area</h3>
# modified: lib/simplegit.rb
#</code></pre>
-<p>Now we can stage and commit that file into a second commit:</p>
+<p>We can stage and commit that file into a second commit:</p>
<pre><code>$ git commit -a -m &#39;added a staging command to the library&#39;
[master]: created bbaee85: &quot;added a staging command to the library&quot;
@@ -169,9 +171,9 @@ <h3 id='using_the_staging_area'>using the staging area</h3>
#
nothing to commit (working directory clean)</code></pre>
-<p>Now we have all our changes stored in two commits thematically, so that it can be easier for our collaborators to understand what we&#8217;ve been working on. After the last file is committed, we can see that the &#8216;git status&#8217; command tells us that our working directory is clean (and also that our current branch has two commits that we haven&#8217;t pushed yet).</p>
+<p>Now we have all our changes stored in two commits thematically, so that it can be easier for our collaborators to understand what we&#8217;ve been working on. After the last file is committed we can see that the &#8216;git status&#8217; command tells us that our working directory is clean (and also that our current branch has two commits that we haven&#8217;t pushed yet).</p>
-<p>If during the &#8216;staging&#8217; part of this workflow you want to see not just want files have changed or are staged, but what the differences are, you can use the <code>git diff</code> command to find that out.</p>
+<p>If during the &#8216;staging&#8217; part of this workflow you want to see not just what files have changed or are staged, but what the differences are, you can use the <code>git diff</code> command to find that out.</p>
<h3 id='changes_that_have_not_been_staged'>changes that have not been staged</h3>
@@ -196,7 +198,7 @@ <h3 id='changes_that_have_not_been_staged'>changes that have not been staged</h3
# modified: lib/simplegit.rb
#</code></pre>
-<p>However, what was actually changed in &#8216;simplegit.rb&#8217;? How can I see what changes I&#8217;ve made that I&#8217;m going to stage? The answer is to just run &#8216;git diff&#8217; with no arguments.</p>
+<p>However, what was actually changed in &#8216;simplegit.rb&#8217;? How can I see what changes I&#8217;ve made that I&#8217;m going to stage? The answer is to run &#8216;git diff&#8217; with no arguments.</p>
<pre><code>$ git diff
diff --git a/lib/simplegit.rb b/lib/simplegit.rb
@@ -232,11 +234,11 @@ <h3 id='changes_that_are_staged_but_not_committed'>changes that are staged but n
Magnus O. Chacon (mchacon@gmail.com)
+ Josephine Chacon (jo.chacon@gmail.com)</code></pre>
-<p>This is a very useful command, because it tells you what changes you&#8217;re introducing were you to run &#8216;git commit&#8217; (without the &#8216;-a&#8217;) at that point.</p>
+<p>This is a very useful command because it tells you what changes you&#8217;re introducing were you to run &#8216;git commit&#8217; (without the &#8216;-a&#8217;) at that point.</p>
<p>OK, now we&#8217;ve seen how to modify, stage and commit changes to files. Next we&#8217;ll look at one of the killer features of Git, its branching model.</p>
-<p>For more information on basic Git usage, you can read <a href='http://progit.org/book/ch2-0.html'>Chapter 2</a> of the Pro Git book.</p><br/><br/><hr/></div><div class="span-10"><a href="setup.html">&laquo; previous</a></div><div style="text-align:right" class="span-11 last"><a href="branching.html">next &raquo;</a></div><div class="span-24 last">&nbsp;</div><hr/>
+<p>For more information on basic Git usage, you can read <a href='http://git-scm.com/book/en/Git-Basics'>Chapter 2</a> of the Pro Git book.</p><br/><br/><hr/></div><div class="span-10"><a href="setup.html">&laquo; previous</a></div><div style="text-align:right" class="span-11 last"><a href="branching.html">next &raquo;</a></div><div class="span-24 last">&nbsp;</div><hr/>
</div>
<div id="footer" class="span-21">
View
47 pages/normal.markdown
@@ -1,7 +1,7 @@
So you have a Git repository and everything is all setup. What now?
Generally, it is not going to be much different than working with any other
-source control system, the only real difference should be the staging process.
+source control system. The only real difference should be the staging process.
The workflow will generally go something like this:
* modify files
@@ -10,7 +10,7 @@ The workflow will generally go something like this:
* commit your staged changes
* rinse, repeat
-That is the most complex case - if you're not collaborating with anyone and so
+That is the most complex case. If you're not collaborating with anyone and so
have no upstream repository to push to, and you want to ignore the staging area,
it can be as simple as:
@@ -33,15 +33,17 @@ If you want to follow along, you can clone the project from
$ cd simplegit
For this first example we'll modify the README file to add ourselves as an
-author on the project. So we simply edit the file. Now we want to commit
+author on the project.
+
+First, we simply edit the file. Now we want to commit
that change, so we run the 'git commit -a' command. The '-a' tells Git to
stage all modified files and then commit - we'll cover the 'staging area' next,
but for now just running 'git commit -a' will act something like the 'commit'
command in SVN.
-A prompt for a commit message
-will open in our editor (the $EDITOR environment variable or 'core.editor' git config
-variable - by default it uses 'vim') that looks like this:
+A prompt for a commit message will open in our editor (the $EDITOR environment
+variable or 'core.editor' git config variable - by default it uses 'vim')
+that looks like this:
_
# Please enter the commit message for your changes. Lines starting
@@ -64,17 +66,16 @@ We simply type our commit message and exit the editor.
Git will show us the commit message we typed and some statistics about what
changes were introduced in that commit. It will also give us a checksum of the
-commit, '5896d4d', that we can use to refer to this exact commit at any other
-time.
+commit, '5896d4d', that we can use to refer to this exact commit later on.
That's it - that's the simple case. Edit files, 'git commit -a', repeat.
### using the staging area ###
Now we're going to cover how to more carefully craft commits using what Git
-calles the 'staging area'. For this example, let's say that we have updated
-your files like we did in the previous section. However,
-now let's imagine that we wanted to commit the changes we've made as two
+calls the 'staging area'. For this example, let's say that we have updated
+your files like we did in the previous section. However, let's now imagine
+that we wanted to commit the changes we've made as two
separate commits rather than one. We can see what has been changed in our
working directory by using the 'git status' command.
@@ -96,7 +97,7 @@ will happen. You have to **stage** a file before you can commit it.
![Git Staging Workflow](../images/staging.png)
So, let's stage the files. Git uses the 'git add' command both to begin tracking
-files and also to stage changes to them. So let's stage the changes in just
+files and also to stage changes to them. We'll stage the changes in just
the README file, then take a look at our status again.
$ git add README
@@ -113,18 +114,18 @@ the README file, then take a look at our status again.
#
# modified: lib/simplegit.rb
-Now the 'lib/simplegit.rb' file is still unstaged, but the README file is now
-under the 'Changes to be committed' section - it is **staged**. Now if we run
+The 'lib/simplegit.rb' file is still unstaged, but the README file is now
+under the 'Changes to be committed' section - it is **staged**. If we run
the commit command (without the -a, which automatically stages everything), only
-the changes to that file will go into the commit - the simplegit.rb file will
-remain unstaged. In this instance, we'll use the '-m' option to 'git commit'
+the changes to that file will go into the commit - the 'simplegit.rb' file will
+remain unstaged. In this instance, we'll use the '-m' option with 'git commit'
to specify the commit message on the command line.
$ git commit -m 'updated the README'
[master]: created 14bb3c6: "updated the README"
1 files changed, 1 insertions(+), 2 deletions(-)
-Now if we run 'git status' again, we can see that the staged file is now
+If we run 'git status' again, we can see that the staged file is now
committed and all we have left is the unstaged 'simplegit.rb' file.
$ git status
@@ -138,7 +139,7 @@ committed and all we have left is the unstaged 'simplegit.rb' file.
# modified: lib/simplegit.rb
#
-Now we can stage and commit that file into a second commit:
+We can stage and commit that file into a second commit:
$ git commit -a -m 'added a staging command to the library'
[master]: created bbaee85: "added a staging command to the library"
@@ -151,11 +152,11 @@ Now we can stage and commit that file into a second commit:
Now we have all our changes stored in two commits thematically, so that it can
be easier for our collaborators to understand what we've been working on. After
-the last file is committed, we can see that the 'git status' command tells us
+the last file is committed we can see that the 'git status' command tells us
that our working directory is clean (and also that our current branch has two
commits that we haven't pushed yet).
-If during the 'staging' part of this workflow you want to see not just want files
+If during the 'staging' part of this workflow you want to see not just what files
have changed or are staged, but what the differences are, you can use the `git diff`
command to find that out.
@@ -187,7 +188,7 @@ and simplegit.rb is modified but not yet staged.
#
However, what was actually changed in 'simplegit.rb'? How can I see what
-changes I've made that I'm going to stage? The answer is to just run 'git diff'
+changes I've made that I'm going to stage? The answer is to run 'git diff'
with no arguments.
$ git diff
@@ -227,11 +228,11 @@ In order to see the changes that have been staged already, you can pass the
Magnus O. Chacon (mchacon@gmail.com)
+ Josephine Chacon (jo.chacon@gmail.com)
-This is a very useful command, because it tells you what changes you're introducing
+This is a very useful command because it tells you what changes you're introducing
were you to run 'git commit' (without the '-a') at that point.
OK, now we've seen how to modify, stage and commit changes to files. Next we'll
look at one of the killer features of Git, its branching model.
-For more information on basic Git usage, you can read [Chapter 2](http://progit.org/book/ch2-0.html)
+For more information on basic Git usage, you can read [Chapter 2](http://git-scm.com/book/en/Git-Basics)
of the Pro Git book.
Please sign in to comment.
Something went wrong with that request. Please try again.