diff --git a/_layouts/reference.html b/_layouts/reference.html index 1dff4bd..40ff38e 100755 --- a/_layouts/reference.html +++ b/_layouts/reference.html @@ -69,6 +69,7 @@
diff --git a/remotes/index.html b/remotes/index.html index 8cb62d1..57f81b7 100644 --- a/remotes/index.html +++ b/remotes/index.html @@ -10,13 +10,152 @@ layout: reference 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 + 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 + is a Git repository and you can syncronize between any two easily. +
+ +Once you have a Git repository, either one that you set up on your + own server, or one hosted someplace like GitHub, you can tell Git to + either push any data that you have that is not in the remote repository + up, or you can ask Git to fetch differences down from the other repo. +
+ +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
+ 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
.
+ and share your changes with git push
. You can manage your
+ remote repositories with git remote
.
Unline 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 + 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
+ 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.
Without any arguments, Git will simply show you the remote repository
+ 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
+ actual URL for each alias.
+$ git remote +origin +$ git remote -v +origin git@github.com:schacon/git-reference.git (fetch) +origin git@github.com:schacon/git-reference.git (push) ++ +
You see the URL there twice because Git allows you to have different + push and fetch URLs for each remote in case you want to use different + protocols for reads and writes.
+ +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
+ 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, + 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 + we would do this:
+ ++$ git remote +$ git remote add github git@github.com:schacon/hw.git +$ git remote -v +github git@github.com:schacon/hw.git (fetch) +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
+ this case I've decided to name my remote 'github', but I could have really
+ named it just about anything.
+
Git addeth and Git taketh away. If you need to remove a remote - you are
+ not using it anymore, the project is gone, etc - you can remove it with
+ git remote rm [alias]
.
+$ git remote -v +github git@github.com:schacon/hw.git (fetch) +github git@github.com:schacon/hw.git (push) +$ git remote add origin git://github.com/pjhyett/hw.git +$ git remote -v +github git@github.com:schacon/hw.git (fetch) +github git@github.com:schacon/hw.git (push) +origin git://github.com/pjhyett/hw.git (fetch) +origin git://github.com/pjhyett/hw.git (push) +$ git remote rm origin +$ git remote -v +github git@github.com:schacon/hw.git (fetch) +github git@github.com:schacon/hw.git (push) ++ +
+ 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
+ add new remotes and git remote rm
to delete existing ones.
+
Cool.
+Git has two commands to update itself from a remote repository.