From b7ce6278ea391972915d9945e90fdc9af82a2629 Mon Sep 17 00:00:00 2001
From: Aaron Beckerman
Once you have a Git repository, either one that you set up on your @@ -54,12 +54,12 @@ layout: reference
Unlike centralized version control systems that have a client that is very different from a server, Git repositories are all basically equal and - you simply syncronize between them. This makes it easy to have more than + you simply synchronize between them. This makes it easy to have more than one remote repository - you can have some that you have read-only access to 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
+ time you want to synchronize 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.
Git has two commands to update itself from a remote repository.
- git fetch
will syncronize you with another repo, pulling down any data
+ git fetch
will synchronize you with another repo, pulling down any data
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
+ that remote was when you synchronized. These are called "remote branches" and are
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.
+ them, etc. You do all of that stuff locally after you synchronize.
The second command that will fetch down new data from a remote server is @@ -238,11 +238,11 @@ From github.com:schacon/hw
If you have more than one remote repository, you can either fetch from specific
- ones by running git fetch [alias]
or you can tell Git to syncronize
+ ones by running git fetch [alias]
or you can tell Git to synchronize
with all of your remotes by running git fetch --all
.
- In a nutshell you run git fetch [alias]
to syncronize your
+ In a nutshell you run git fetch [alias]
to synchronize your
repository with a remote repository, fetching all the data it has that you do
not into branch references locally for merging and whatnot.
fetch
and merge
seperately. Less magic, less problems. However, if you like this idea, you
- can read about it in more detail in the.
+ can read about it in more detail in the
official docs.
From 600d19ef968f71f1ac20e2dbd9aa77e0c8b3e6f7 Mon Sep 17 00:00:00 2001
From: Aaron Beckerman Pretty easy. Now if someone clones that repository they will get exactly - what I have committed and all of it's history.
+ what I have committed and all of its history.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.
From fd1a47085e796612a0d3b9ea11aaec49e39f0858 Mon Sep 17 00:00:00 2001
From: Aaron Beckerman Now when people clone or fetch from that repository, they'll get a 'erlang'
+ Now when people clone or fetch from that repository, they'll get an 'erlang'
branch they can look at and merge from. You can push any branch to any
remote repository that you have write access to in this way. If your branch
is already on the server, it will try to update it, if it is not, Git will
From 21288a78480a9e934e78987e900a4dbb78f3b5a4 Mon Sep 17 00:00:00 2001
From: Aaron Beckerman
From 58122075f07bf409072af58b72135035f9c79204 Mon Sep 17 00:00:00 2001
From: Aaron Beckerman
Let's start from scratch. Assume you are designing a new source
- code management system. How do you do basic version control before
+ code management system. How did you do basic version control before
you used a tool for it? Chances are that you simply copied your
project directory to save what it looked like at that point.
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
+ makes sure it can see the current tip of the server's branch in your push's
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
From 67e3faf764a09152a83f5ea0f1d11f9b622110b6 Mon Sep 17 00:00:00 2001
From: Aaron Beckerman