Merge pull request #57 from randomecho/pronoun-wash
Remove pronoun I from voice for lack of lone addressor
This commit is contained in:
commit
5d37cc7a43
@ -140,8 +140,8 @@ layout: reference
|
|||||||
<div class="block">
|
<div class="block">
|
||||||
<p>As you saw in the <code>git add</code> section, in order to see what the
|
<p>As you saw in the <code>git add</code> section, in order to see what the
|
||||||
status of your staging area is compared to the code in your working
|
status of your staging area is compared to the code in your working
|
||||||
directory, you can run the <code>git status</code> command. I demonstrated
|
directory, you can run the <code>git status</code> command. Using the
|
||||||
using it with the <code>-s</code> option, which gives you short output.
|
<code>-s</code> option will give you short output.
|
||||||
Without that flag, the <code>git status</code> command will give you more
|
Without that flag, the <code>git status</code> command will give you more
|
||||||
context and hints. Here is the same status output with and without the
|
context and hints. Here is the same status output with and without the
|
||||||
<code>-s</code>. The short output looks like this:
|
<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
|
<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 commit</code>, Git will simply give you the output of the
|
||||||
<code>git status</code> command, reminding you that nothing is staged.
|
<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
|
is added to be committed. If you use <code>-a</code>, it will add and
|
||||||
commit everything at once.
|
commit everything at once.
|
||||||
</p>
|
</p>
|
||||||
@ -605,11 +605,9 @@ Further paragraphs come after blank lines.
|
|||||||
|
|
||||||
<div class="block">
|
<div class="block">
|
||||||
<p><code>git reset</code> is probably the most confusing command written
|
<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
|
by humans, but it can be very useful when you get the hang of it.
|
||||||
still get confused by what it is going to do at times. So, I'll just
|
There are three specific invocations of it that are generally
|
||||||
tell you the three specific invocations of it that are generally
|
helpful.
|
||||||
helpful and ask you to blindly use it as I do - because it can be
|
|
||||||
very useful.
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<h4>
|
<h4>
|
||||||
@ -617,19 +615,19 @@ Further paragraphs come after blank lines.
|
|||||||
<small>undo the last commit and unstage the files</small>
|
<small>undo the last commit and unstage the files</small>
|
||||||
</h4>
|
</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
|
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
|
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
|
one, then stage and commit the other. If you accidentally stage both of
|
||||||
them, how do you <i>un-</i>stage one? You do it with
|
them, how do you <i>un-</i>stage one? You do it with
|
||||||
<code>git reset HEAD -- file</code>. Technically here you don't have to
|
<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
|
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
|
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
|
get into the habit of using it to separate options from paths even if you
|
||||||
don't need to.
|
don't need to.
|
||||||
</p>
|
</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
|
two files that have been modified since our last commit. We will stage
|
||||||
both, then unstage one of them.</p>
|
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.
|
<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"
|
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
|
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
|
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>
|
included in the next commit snapshot, thereby effectively deleting it.</p>
|
||||||
@ -810,10 +808,10 @@ nothing to commit (working directory clean)
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p class="aside">
|
<p class="aside">
|
||||||
I personally don't use this command that much in it's normal form - to
|
In its normal form the command is used to delete files.
|
||||||
delete files. It's often easier to just remove the files off your disk and
|
But 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
|
then run <code>git commit -a</code>, which will also automatically remove
|
||||||
from your index, too.</p>
|
them from your index.</p>
|
||||||
|
|
||||||
<p class="nutshell">
|
<p class="nutshell">
|
||||||
<strong>In a nutshell</strong>,
|
<strong>In a nutshell</strong>,
|
||||||
|
@ -10,7 +10,7 @@ layout: reference
|
|||||||
Branching and Merging
|
Branching and Merging
|
||||||
</h2>
|
</h2>
|
||||||
<div class="block">
|
<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
|
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
|
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
|
practically as <i>contexts</i> since that is how you will most often be
|
||||||
@ -319,7 +319,7 @@ HelloWorld.hello
|
|||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>So first we're going to create a new branch named 'change_class' and
|
<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>
|
change each instance of 'HelloWorld' to 'HiWorld'.</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
@ -333,9 +333,9 @@ class HiWorld
|
|||||||
1 files changed, 2 insertions(+), 4 deletions(-)
|
1 files changed, 2 insertions(+), 4 deletions(-)
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>So now I've committed the class renaming changes to the 'change_class'
|
<p>So now we've committed the class renaming changes to the 'change_class'
|
||||||
branch. If I now switch back to the 'master' branch my class name will
|
branch. To switch back to the 'master' branch the class name will
|
||||||
revert to what it was before I switched branches. Here I can change
|
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
|
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>.
|
time rename the file from <code>hello.rb</code> to <code>ruby.rb</code>.
|
||||||
</p>
|
</p>
|
||||||
@ -365,10 +365,10 @@ index 2aabb6e..bf64b17 100644
|
|||||||
rename hello.rb => ruby.rb (65%)
|
rename hello.rb => ruby.rb (65%)
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>Now those changes are recorded in my 'master' branch. Notice that the
|
<p>Now those changes are recorded in the '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'. To incorporate
|
||||||
incorporate the 'HiWorld' change so I can just merge in my 'change_class'
|
the 'HiWorld' change we can just merge in the 'change_class'
|
||||||
branch. However, I've changed the name of the file since I branched,
|
branch. However, the name of the file has changed since we branched,
|
||||||
what will Git do?</p>
|
what will Git do?</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
@ -391,7 +391,7 @@ end
|
|||||||
HiWorld.hello
|
HiWorld.hello
|
||||||
</pre>
|
</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
|
and the file that had been renamed now has the 'HiWorld' class name change
|
||||||
that was done in the other branch. Pretty cool.</p>
|
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
|
<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
|
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> -
|
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>
|
<pre>
|
||||||
<b>$ git status -s</b>
|
<b>$ git status -s</b>
|
||||||
@ -684,7 +684,7 @@ b7ae93b added from ruby
|
|||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>This way, it's pretty easy to see that we have Haskell code included in
|
<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
|
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
|
reachable in one branch that are not reachable in another, in other words
|
||||||
which commits are unique to a branch in comparison to another.
|
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
|
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
|
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
|
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>
|
<pre>
|
||||||
<b>$ git tag -a v1.0 </b>
|
<b>$ git tag -a v1.0 </b>
|
||||||
|
@ -5,7 +5,7 @@ layout: reference
|
|||||||
<h2>Introduction to the Git Reference</h2>
|
<h2>Introduction to the Git Reference</h2>
|
||||||
<div class="block">
|
<div class="block">
|
||||||
<p>
|
<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
|
reference for learning and remembering the most important and
|
||||||
commonly used Git commands. The commands are organized into
|
commonly used Git commands. The commands are organized into
|
||||||
sections of the type of operation you may be trying to do, and
|
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>
|
<h2>How to Think Like Git</h2>
|
||||||
<div class="block">
|
<div class="block">
|
||||||
<p>
|
<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
|
that it thinks about version control very differently than
|
||||||
Subversion or Perforce or whatever SCM you may be used to. It
|
Subversion or Perforce or whatever SCM you may be used to. It
|
||||||
is often easier to learn Git by trying to forget your assumptions
|
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
|
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
|
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
|
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
|
case sensitive and will also search the email address. The following
|
||||||
example using the <code>-[number]</code> option, which will limit the
|
example will use the <code>-[number]</code> option, which will limit the
|
||||||
results to the last [number] commits.
|
results to the last [number] commits.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
@ -78,11 +78,11 @@ b532581 make "git unpack-file" a built-in
|
|||||||
|
|
||||||
<p>
|
<p>
|
||||||
If you want to specify a date range that you're interested in filtering your
|
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>
|
commits down to, you can use a number of options such as <code>--since</code>
|
||||||
and <code>--before</code>, but you can also use <code>--until</code> and
|
and <code>--before</code>, or you can also use <code>--until</code> and
|
||||||
<code>--after</code>. For example, if I wanted to see all the commits in
|
<code>--after</code>. For example, to see all the commits in
|
||||||
the Git project before 3 weeks ago but after April 18th, I could run this
|
the Git project before three weeks ago but after April 18th, you could run this
|
||||||
(I'm also going to use <code>--no-merges</code> to remove merge commits):
|
(We're also going to use <code>--no-merges</code> to remove merge commits):
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
@ -105,9 +105,9 @@ b6c8d2d Documentation/remote-helpers: Add invocation section
|
|||||||
|
|
||||||
<p>
|
<p>
|
||||||
You may also want to look for commits with a certain phrase in the commit
|
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
|
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>.
|
with <code>--grep</code>.
|
||||||
</p>
|
</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>
|
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
|
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
|
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.
|
who the author of each commit was.
|
||||||
</p>
|
</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>
|
three commits:</p>
|
||||||
|
|
||||||
<pre>
|
<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
|
1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>If I add a <code>--author=Hausmann</code> argument, instead of further
|
<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 me all
|
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>
|
commits by Simon OR commits with "p4 depo" in the message:</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
@ -167,7 +167,7 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface.
|
|||||||
...
|
...
|
||||||
</pre>
|
</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>
|
looking for:</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
@ -438,7 +438,7 @@ index bb86f00..192151c 100644
|
|||||||
the triple-dot syntax, because it will almost always give you what you want.
|
the triple-dot syntax, because it will almost always give you what you want.
|
||||||
</p>
|
</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
|
merge-base (first common ancestor commit) of any two commits would be with
|
||||||
the <code>git merge-base</code> command:</p>
|
the <code>git merge-base</code> command:</p>
|
||||||
|
|
||||||
@ -447,7 +447,7 @@ index bb86f00..192151c 100644
|
|||||||
8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
|
8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
|
||||||
</pre>
|
</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>
|
by running this:</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
@ -457,7 +457,7 @@ index bb86f00..192151c 100644
|
|||||||
2 files changed, 9 insertions(+), 0 deletions(-)
|
2 files changed, 9 insertions(+), 0 deletions(-)
|
||||||
</pre>
|
</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">
|
<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>
|
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),
|
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".
|
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
|
To add that to our project so we can push to it and fetch updates from it
|
||||||
we would do this:</p>
|
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>
|
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
|
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
|
<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
|
this case we'll name the remote 'github', but you could name it just
|
||||||
named it just about anything.
|
about anything.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<h4>
|
<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
|
<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>
|
<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
|
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
|
that is tracked by whatever branch you are currently in. Running the
|
||||||
like this command - I prefer running <code>fetch</code> and <code>merge</code>
|
<code>fetch</code> and <code>merge</code> commands separately involves less magic
|
||||||
separately. Less magic, less problems. However, if you like this idea, you
|
and less problems, but if you like the idea of <code>pull</code>, you can
|
||||||
can read about it in more detail in the
|
read about it in more detail in the
|
||||||
<a target="new" href="http://git-scm.com/docs/git-pull">official docs</a>.
|
<a target="new" href="http://git-scm.com/docs/git-pull">official docs</a>.
|
||||||
</p>
|
</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
|
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>
|
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
|
(like if someone else has pushed in the meantime). So, if you were working on a
|
||||||
Hello World project with several other people and I wanted to bring in any changes
|
Hello World project with several other people and wanted to bring in any changes
|
||||||
that had been pushed since I last connected, I would do something like this:</p>
|
that had been pushed since we last connected, we would do something like this:</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
<b>$ git fetch github</b>
|
<b>$ git fetch github</b>
|
||||||
@ -296,17 +296,17 @@ From github.com:schacon/hw
|
|||||||
* [new branch] lisp -> github/lisp
|
* [new branch] lisp -> github/lisp
|
||||||
</pre>
|
</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
|
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
|
'master', 'c-langs' and 'java' branches have been updated. In our example case,
|
||||||
is pushing proposed updates to remote branches for review before they're merged
|
other developers are pushing proposed updates to remote branches for review before
|
||||||
into 'master'.
|
they're merged into 'master'.
|
||||||
</p>
|
</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
|
repository becomes a branch named 'github/master' locally. That way you can
|
||||||
merge the 'master' branch on that remote into my local 'master' branch by running
|
merge the 'master' branch on that remote into the local 'master' branch by running
|
||||||
<code>git merge github/master</code>. Or, I can see what new commits are on that
|
<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
|
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
|
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.
|
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>
|
</pre>
|
||||||
|
|
||||||
<p>Pretty easy. Now if someone clones that repository they will get exactly
|
<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
|
<p>What if you have a topic branch like the 'erlang' branch created earlier
|
||||||
and I just want to share that? You can just push that branch instead.</p>
|
and want to share just that? You can just push that branch instead.</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
<b>$ git push github erlang</b>
|
<b>$ git push github erlang</b>
|
||||||
|
Loading…
Reference in New Issue
Block a user