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.

+
+

+ + docs   + book + + git remote + list, add and delete remote repository aliases +

+ +
+ +

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.

+ +

+ git remote + list your remote aliases +

+ +

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.

+ +

+ git remote add + add a new remote repository of your project +

+ +

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 remote rm + removing an existing remote alias +

+ +

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. +

+ +
+
+

@@ -37,9 +176,11 @@ layout: reference git pull fetch from a remote repo and try to merge into the current branch

+
-

Cool.

+

Git has two commands to update itself from a remote repository.

+