最近准备给同事培训git，发现了一个不错的资源，在这里：http://www.gitguys.com/topics/creating-a-shared-repository-users-sharing-the-repository/
原文如下，有空再译：
ommands discussed in this section:
- git init –bare
- git clone
- git remote
- git pull
- git push
Scenario: Example Remote Repository
Let’s set up our own little “remote” repository and then share it. (The repository will be “remote” to the users sharing it.)
In these examples, the other users sharing the repository will not be very remote since the repository will be on the same disk as the users’ home directories. But the git workflow and commands are identical, whether the users and repositories are just a few millimeters away on the same disk, or on a remote network across the world.
Creating The Shared Repository
We’ll have the repository created by the user gitadmin. The gitadmin‘s repository will be be the repository where everybody on the project both publishes their work and also retrieves the latest work done by others.
The scenario:
- gitadmin will create a repository.
- Other users, like Amy and Zack will then get (“git clone”) copies of gitadmin‘s remote repository.
- Changes will be pulled and pushed to and from gitadmin‘s repository.
Create Shared Repositories “Bare”
If you are creating a git repository for only your own use on projects or days when you just don’t feel like sharing, you type:
gitadmin$ git init project1 Initialized empty Git repository in /home/gitadmin/project1/.git/
However, if you are creating a git repository for sharing with git clone/pull/fetch/push, Use the –bare option to git init:
gitadmin$ git init --bare project1.git Initialized empty Git repository in /home/gitadmin/project1.git/
If you want to know why, see Shared Repositories Should Be Bare Repositories.
Bare Repositories End in “.git”
You might have noticed the –bare repository created above ended in .git. By convention, bare git repositories should end in .git. For example, project1.git or usplash.git, etc. The .git ending of a directory signals to others that the git repository is bare.
Amy is ready to add to the remote repository
In our example, since Amy’s name begins with the first letter of the alphabet, she gets to work on the repository first.
Amy clones it:
amy$ git clone file:///home/gitadmin/project1.git Initialized empty Git repository in /home/amy/project1/.git/ warning: You appear to have cloned an empty repository.
Git just told us the repository that Amy just cloned is empty.
We can now start creating files and publishing (“git push“) them to the shared repository.
Amy wants to see if there are any branches in the repository she just retrieved/cloned:
amy$ cd project1 amy$ git branch amy$
The empty output from the git branch command showed are no branches in the new repository.
Amy creates her first file and commit’s the new file to the repository.
amy$ echo The beginnings of project1 > amy.file amy$ git add . amy$ git commit -m"Amy‘s initial commit" [master (root-commit) 01d7520] Amy‘s initial commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 amy.file amy$ git branch * master
The cloned, bare repository didn’t have any branches, not even the master repository. When Amy did the first git commit, the master branch was created in Amy’s local repository.
Amy tries to publish her local repository to the remote repository:
amy$ git push No refs in common and none specified; doing nothing. Perhaps you should specify a branch such as ‘master‘. fatal: The remote end hung up unexpectedly error: failed to push some refs to ‘file:///home/gitadmin/project1.git‘
Oops, that didn’t work. The above happens on brand new, completely empty, branchless repositories (immediately after doing the git init –bare …).
Amy’s local repository created the master branch, but the shared repository that gitadmin created does not have any branches on it still.
Amy will take git’s advice and tell git the name of the branch she wants pushed to which remote repository. She must specify both the remote repository name and branch name.
What are the branch and repository names? Amy has been distracted lately and forgot the name of remote repository, so she’ll use the git remote command to list the names of her remote repositories:
amy$ git remote origin
She is shown there is only one remote repository named origin. The default remote repository when you git clone a repository is named origin, so the above output isn’t surprising.
Similarly, Amy can find out the branch name in her local repository by using the git branch command:
amy$ git branch * master
The branch name master isn’t surprising either, since master is the default branch name for git.
Armed with the remote repository name (origin) and local branch name (master) Amy can now push (publish) the changes.
The git push syntax is:
git push [remote-repository-name] [branch-or-commit-name].
Amy will push the branch named master to the remote repository named origin:
amy$ git push origin master Counting objects: 3, done. Writing objects: 100% (3/3), 245 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To file:///home/gitadmin/project1.git * [new branch] master -> master
The last line above reports a new branch was created: the master branch (referred to in some places as the “source”) on the local repository was mapped to the master branch (referred to in some places as the “destination”) on the remote repository.
Amy will no longer need to type git push origin master, but will be able to type git push, since the master branch now exists on the remote repository named origin:
amy$ git push Everything up-to-date
Zack wants to play too
Now it’s Zack’s turn to play with the repository. He clones it:
zack$ git clone file:///home/gitadmin/project1.git Initialized empty Git repository in /home/zack/project1/.git/ remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Receiving objects: 100% (3/3), done. zack$ ls amy.file
Above, the file Amy added, amy.file is copied from the shared repository to Zack’s working directory.
Zack adds a file and pushes it up to the shared repository:
zack$ cd project1 zack$ echo I am zack > zack.file zack$ git add . zack$ git commit -m ‘zack initial commit‘ [master 05affb3] zack initial commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 zack.file zack$ git push Counting objects: 4, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 283 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To file:///home/gitadmin/project1.git 01d7520..05affb3 master -> master
Note that Zack didn’t have to do the git push origin master to create the master branch on the remote repository, since Amy had already created the master branch on the remote repository.
Amy wants to get the latest
amy$ git pull remote: Counting objects: 4, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From file:///home/gitadmin/project1 01d7520..05affb3 master -> origin/master Updating 01d7520..05affb3 Fast-forward zack.file | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 zack.file amy$ ls amy.file zack.file
Things are working pretty well: Amy and Zack are sharing nicely: They are contributing to (“git push“) and receiving from (“git pull“) the shared repository.
The above summarizes how to get moving with shared, remote repostitories. But there’s a lot more fun you can have with remote repositories.