Merge pull request #57 from randomecho/pronoun-wash
Remove pronoun I from voice for lack of lone addressor
This commit is contained in:
Matthew McCullough
commit
5d37cc7a43
@ -140,8 +140,8 @@ layout: reference
|
||||
<div class="block">
|
||||
<p>As you saw in the <code>git add</code> section, in order to see what the
|
||||
status of your staging area is compared to the code in your working
|
||||
directory, you can run the <code>git status</code> command. I demonstrated
|
||||
using it with the <code>-s</code> option, which gives you short output.
|
||||
directory, you can run the <code>git status</code> command. Using the
|
||||
<code>-s</code> option will give you short output.
|
||||
Without that flag, the <code>git status</code> command will give you more
|
||||
context and hints. Here is the same status output with and without the
|
||||
<code>-s</code>. The short output looks like this:
|
||||
@ -572,7 +572,7 @@ Further paragraphs come after blank lines.
|
||||
<p>Notice how if you don't stage any changes and then run
|
||||
<code>git commit</code>, Git will simply give you the output of the
|
||||
<code>git status</code> command, reminding you that nothing is staged.
|
||||
I've highlighted the important part of that message, saying that nothing
|
||||
The important part of that message has been highlighted, saying that nothing
|
||||
is added to be committed. If you use <code>-a</code>, it will add and
|
||||
commit everything at once.
|
||||
</p>
|
||||
@ -605,11 +605,9 @@ Further paragraphs come after blank lines.
|
||||
|
||||
<div class="block">
|
||||
<p><code>git reset</code> is probably the most confusing command written
|
||||
by humans. I've been using Git for years, even wrote a book on it and I
|
||||
still get confused by what it is going to do at times. So, I'll just
|
||||
tell you the three specific invocations of it that are generally
|
||||
helpful and ask you to blindly use it as I do - because it can be
|
||||
very useful.
|
||||
by humans, but it can be very useful when you get the hang of it.
|
||||
There are three specific invocations of it that are generally
|
||||
helpful.
|
||||
</p>
|
||||
|
||||
<h4>
|
||||
@ -617,19 +615,19 @@ Further paragraphs come after blank lines.
|
||||
<small>undo the last commit and unstage the files</small>
|
||||
</h4>
|
||||
|
||||
<p>In the first case, we can use it to unstage something that you have
|
||||
<p>First, you can use it to unstage something that has been
|
||||
accidentally staged. Let's say that you have modified two files and want
|
||||
to record them into two different commits. You should stage and commit
|
||||
one, then stage and commit the other. If you accidentally stage both of
|
||||
them, how do you <i>un-</i>stage one? You do it with
|
||||
<code>git reset HEAD -- file</code>. Technically here you don't have to
|
||||
<code>git reset HEAD -- file</code>. Technically you don't have to
|
||||
add the <code>--</code> - it is used to tell Git when you have stopped
|
||||
listing options and are now listing file paths, but it's probably good to
|
||||
get into the habit of using it to separate options from paths even if you
|
||||
don't need to.
|
||||
</p>
|
||||
|
||||
<p>So, let's see what it looks like to unstage something. Here we have
|
||||
<p>Let's see what it looks like to unstage something. Here we have
|
||||
two files that have been modified since our last commit. We will stage
|
||||
both, then unstage one of them.</p>
|
||||
|
||||
@ -782,7 +780,7 @@ nothing to commit (working directory clean)
|
||||
|
||||
<p><code>git rm</code> will remove entries from the staging area.
|
||||
This is a bit different from <code>git reset HEAD</code> which "unstages"
|
||||
files. By "unstage" I mean it reverts the staging area to what was
|
||||
files. To "unstage" means it reverts the staging area to what was
|
||||
there before we started modifying things. <code>git rm</code> on the
|
||||
other hand just kicks the file off the stage entirely, so that it's not
|
||||
included in the next commit snapshot, thereby effectively deleting it.</p>
|
||||
@ -810,10 +808,10 @@ nothing to commit (working directory clean)
|
||||
</p>
|
||||
|
||||
<p class="aside">
|
||||
I personally don't use this command that much in it's normal form - to
|
||||
delete files. It's often easier to just remove the files off your disk and
|
||||
then run a <code>git commit -a</code>, which will automatically remove them
|
||||
from your index, too.</p>
|
||||
In its normal form the command is used to delete files.
|
||||
But it's often easier to just remove the files off your disk and
|
||||
then run <code>git commit -a</code>, which will also automatically remove
|
||||
them from your index.</p>
|
||||
|
||||
<p class="nutshell">
|
||||
<strong>In a nutshell</strong>,
|
||||
|
||||
@ -10,7 +10,7 @@ layout: reference
|
||||
Branching and Merging
|
||||
</h2>
|
||||
<div class="block">
|
||||
<p>Branching in Git is one of my favorite features. If you have used other
|
||||
<p>Branching in Git is one of its many great features. If you have used other
|
||||
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
|
||||
@ -319,7 +319,7 @@ 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
|
||||
switch to it so your class renaming changes are isolated. We're going to
|
||||
change each instance of 'HelloWorld' to 'HiWorld'.</p>
|
||||
|
||||
<pre>
|
||||
@ -333,9 +333,9 @@ class HiWorld
|
||||
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
|
||||
<p>So now we've committed the class renaming changes to the 'change_class'
|
||||
branch. To switch back to the 'master' branch the class name will
|
||||
revert to what it was before we switched branches. Here we 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>.
|
||||
</p>
|
||||
@ -365,10 +365,10 @@ index 2aabb6e..bf64b17 100644
|
||||
rename hello.rb => ruby.rb (65%)
|
||||
</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
|
||||
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,
|
||||
<p>Now those changes are recorded in the 'master' branch. Notice that the
|
||||
class name is back to 'HelloWorld', not 'HiWorld'. To incorporate
|
||||
the 'HiWorld' change we can just merge in the 'change_class'
|
||||
branch. However, the name of the file has changed since we branched,
|
||||
what will Git do?</p>
|
||||
|
||||
<pre>
|
||||
@ -391,7 +391,7 @@ end
|
||||
HiWorld.hello
|
||||
</pre>
|
||||
|
||||
<p>Well, it will just figure it out. Notice that I had no merge conflicts
|
||||
<p>Well, it will just figure it out. Notice that there are no merge conflicts
|
||||
and the file that had been renamed now has the 'HiWorld' class name change
|
||||
that was done in the other branch. Pretty cool.</p>
|
||||
|
||||
@ -474,9 +474,9 @@ index 9103e27,69cad1a..0000000
|
||||
|
||||
<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
|
||||
and how you've resolved it as shown here. Now it's time to mark
|
||||
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>
|
||||
to tell Git the file has been resolved you have to stage it.</p>
|
||||
|
||||
<pre>
|
||||
<b>$ git status -s</b>
|
||||
@ -684,7 +684,7 @@ 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 (highlighted in the output). 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.
|
||||
@ -751,7 +751,7 @@ ab5ab4c added erlang
|
||||
tag", which allows you to add a tag message to it, which is what you almost
|
||||
always want to do. Running this without the <code>-a</code> works too, but
|
||||
it doesn't record when it was tagged, who tagged it, or let you add a tag
|
||||
message. I would recommend always creating annotated tags.</p>
|
||||
message. It's recommended you always create annotated tags.</p>
|
||||
|
||||
<pre>
|
||||
<b>$ git tag -a v1.0 </b>
|
||||
|
||||
@ -5,7 +5,7 @@ layout: reference
|
||||
<h2>Introduction to the Git Reference</h2>
|
||||
<div class="block">
|
||||
<p>
|
||||
This is the Git reference site. This is meant to be a quick
|
||||
This is the Git reference site. It is meant to be a quick
|
||||
reference for learning and remembering the most important and
|
||||
commonly used Git commands. The commands are organized into
|
||||
sections of the type of operation you may be trying to do, and
|
||||
@ -28,7 +28,7 @@ layout: reference
|
||||
<h2>How to Think Like Git</h2>
|
||||
<div class="block">
|
||||
<p>
|
||||
The first thing that is important to understand about Git is
|
||||
The first important thing to understand about Git is
|
||||
that it thinks about version control very differently than
|
||||
Subversion or Perforce or whatever SCM you may be used to. It
|
||||
is often easier to learn Git by trying to forget your assumptions
|
||||
|
||||
@ -57,8 +57,8 @@ layout: reference
|
||||
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
|
||||
case sensitive and also will search the email address. I'll do the
|
||||
example using the <code>-[number]</code> option, which will limit the
|
||||
case sensitive and will also search the email address. The following
|
||||
example will use the <code>-[number]</code> option, which will limit the
|
||||
results to the last [number] commits.
|
||||
</p>
|
||||
|
||||
@ -78,11 +78,11 @@ 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
|
||||
<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):
|
||||
commits down to, you can use a number of options such as <code>--since</code>
|
||||
and <code>--before</code>, or you can also use <code>--until</code> and
|
||||
<code>--after</code>. For example, to see all the commits in
|
||||
the Git project before three weeks ago but after April 18th, you could run this
|
||||
(We're also going to use <code>--no-merges</code> to remove merge commits):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
@ -105,9 +105,9 @@ 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
|
||||
message. Use <code>--grep</code> for that. Let's say there
|
||||
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
|
||||
you wanted to remember what that change looked like - you could find the commit
|
||||
with <code>--grep</code>.
|
||||
</p>
|
||||
|
||||
@ -132,11 +132,11 @@ Date: Wed Mar 12 19:03:24 2008 -0500
|
||||
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
|
||||
examples we're going to use the <code>--format</code> option, so we can see
|
||||
who the author of each commit was.
|
||||
</p>
|
||||
|
||||
<p>If I look for the commit messages with 'p4 depo' in them, I get these
|
||||
<p>If we look for the commit messages with 'p4 depo' in them, we get these
|
||||
three commits:</p>
|
||||
|
||||
<pre>
|
||||
@ -146,8 +146,8 @@ 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
|
||||
filtering it down to the one commit by Simon, it instead will show me all
|
||||
<p>If we add a <code>--author=Hausmann</code> argument, instead of further
|
||||
filtering it down to the one commit by Simon, it instead will show all
|
||||
commits by Simon OR commits with "p4 depo" in the message:</p>
|
||||
|
||||
<pre>
|
||||
@ -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, adding <code>--all-match</code> will get the results you're
|
||||
looking for:</p>
|
||||
|
||||
<pre>
|
||||
@ -438,7 +438,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 what the
|
||||
merge-base (first common ancestor commit) of any two commits would be with
|
||||
the <code>git merge-base</code> command:</p>
|
||||
|
||||
@ -447,7 +447,7 @@ index bb86f00..192151c 100644
|
||||
8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
|
||||
</pre>
|
||||
|
||||
<p>So, you can do the equivalent of <code>git diff master...erlang</code>
|
||||
<p>You can do the equivalent of <code>git diff master...erlang</code>
|
||||
by running this:</p>
|
||||
|
||||
<pre>
|
||||
@ -457,7 +457,7 @@ index bb86f00..192151c 100644
|
||||
2 files changed, 9 insertions(+), 0 deletions(-)
|
||||
</pre>
|
||||
|
||||
<p>I would of course recommend using the easier syntax, though.</p>
|
||||
<p>You may prefer using the easier syntax though.</p>
|
||||
|
||||
|
||||
<p class="nutshell">
|
||||
|
||||
@ -100,7 +100,7 @@ origin git@github.com:github/git-reference.git (push)
|
||||
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,
|
||||
we can create a new repository on a server (I'll use GitHub as an example),
|
||||
we can create a new repository on a server (Using 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
|
||||
we would do this:</p>
|
||||
@ -117,8 +117,8 @@ github git@github.com:schacon/hw.git (push)
|
||||
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.
|
||||
this case we'll name the remote 'github', but you could name it just
|
||||
about anything.
|
||||
</p>
|
||||
|
||||
<h4>
|
||||
@ -266,10 +266,10 @@ fatal: No such remote 'guhflub'
|
||||
<p>The second command that will fetch down new data from a remote server is
|
||||
<code>git pull</code>. This command will basically run a <code>git fetch</code>
|
||||
immediately followed by a <code>git merge</code> of the branch on that remote
|
||||
that is tracked by whatever branch you are currently in. I personally don't much
|
||||
like this command - I prefer running <code>fetch</code> and <code>merge</code>
|
||||
separately. Less magic, less problems. However, if you like this idea, you
|
||||
can read about it in more detail in the
|
||||
that is tracked by whatever branch you are currently in. Running the
|
||||
<code>fetch</code> and <code>merge</code> commands separately involves less magic
|
||||
and less problems, but if you like the idea of <code>pull</code>, you can
|
||||
read about it in more detail in the
|
||||
<a target="new" href="http://git-scm.com/docs/git-pull">official docs</a>.
|
||||
</p>
|
||||
|
||||
@ -277,9 +277,9 @@ fatal: No such remote 'guhflub'
|
||||
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
|
||||
(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>
|
||||
(like if someone else has pushed in the meantime). So, if you were working on a
|
||||
Hello World project with several other people and wanted to bring in any changes
|
||||
that had been pushed since we last connected, we would do something like this:</p>
|
||||
|
||||
<pre>
|
||||
<b>$ git fetch github</b>
|
||||
@ -296,17 +296,17 @@ From github.com:schacon/hw
|
||||
* [new branch] lisp -> github/lisp
|
||||
</pre>
|
||||
|
||||
<p>I can see that since the last time I synchronized with this remote, five branches
|
||||
<p>Here we can see that since we last synchronized with this remote, five branches
|
||||
have been added or updated. The 'ada' and 'lisp' branches are new, where the
|
||||
'master', 'c-langs' and 'java' branches have been updated. In this case, my team
|
||||
is pushing proposed updates to remote branches for review before they're merged
|
||||
into 'master'.
|
||||
'master', 'c-langs' and 'java' branches have been updated. In our example case,
|
||||
other developers are pushing proposed updates to remote branches for review before
|
||||
they're merged into 'master'.
|
||||
</p>
|
||||
|
||||
<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
|
||||
repository becomes a branch named 'github/master' locally. That way you can
|
||||
merge the 'master' branch on that remote into the local 'master' branch by running
|
||||
<code>git merge github/master</code>. Or, you can see what new commits are on that
|
||||
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.
|
||||
@ -356,10 +356,10 @@ To git@github.com:schacon/hw.git
|
||||
</pre>
|
||||
|
||||
<p>Pretty easy. Now if someone clones that repository they will get exactly
|
||||
what I have committed and all of its history.</p>
|
||||
what we have committed and all of its history.</p>
|
||||
|
||||
<p>What if I have a topic branch like the 'erlang' branch we created earlier
|
||||
and I just want to share that? You can just push that branch instead.</p>
|
||||
<p>What if you have a topic branch like the 'erlang' branch created earlier
|
||||
and want to share just that? You can just push that branch instead.</p>
|
||||
|
||||
<pre>
|
||||
<b>$ git push github erlang</b>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user