假設Alice現在開始了一個新項目，在/home/alice/project建了一個新的git 倉庫(repository)；另一個叫Bob的工作目錄也在同一臺機器，他要提交代碼。 Bob 執行了這樣的命令: ~~~ $ git clone /home/alice/project myrepo ~~~ 這就建了一個新的叫"myrepo"的目錄，這個目錄里包含了一份Alice的倉庫的 克隆(clone). 這份克隆和原始的項目一模一樣，并且擁有原始項目的歷史記 錄。 Bob 做了一些修改并且提交(commit)它們: ~~~ (edit files) $ git commit -a (repeat as necessary) ~~~ 當他準備好了，他告訴Alice從倉庫/home/bob/myrepo中把他的修改給拉 (pull)下來。她執行了下面幾條命令: ~~~ $ cd /home/alice/project $ git pull /home/bob/myrepo master ~~~ 這就把Bob的主(master)分支合并到了Alice的當前分支里了。如果Alice在 Bob修改文件內容的同時也做了修改的話，她可能需要手工去修復沖突. (注意："master"參數在上面的命令中并不一定是必須的，因為這是一個 默認參數) git pull命令執行兩個操作: 它從遠程分支(remote branch)抓取修改 的內容，然后把它合并進當前的分支。 如果你要經常操作遠程分支(remote branch),你可以定義它們的縮寫: ~~~ $ git remote add bob /home/bob/myrepo ~~~ 這樣，Alic可以用"git fetch"" 來執行"git pull"前半部分的工作， 但是這條命令并不會把抓下來的修改合并到當前分支里。 ~~~ $ git fetch bob ~~~ 我們用`git remote`命令建立了Bob的運程倉庫的縮寫，用這個(縮寫) 名字我從Bob那得到所有遠程分支的歷史記錄。在這里遠程分支的名 字就叫`bob/master`. ~~~ $ git log -p master..bob/master ~~~ 上面的命令把Bob從Alice的主分支(master)中簽出后所做的修改全部顯示出來。 當檢查完修改后,Alice就可以把修改合并到她的主分支中。 ~~~ $ git merge bob/master ~~~ 這種合并(merge)也可以用pull來完成，就像下面的命令一樣： ~~~ $ git pull . remotes/bob/master ~~~ 注意：git pull 會把遠程分支合并進當前的分支里，而不管你在命令 行里指定什么。 其后，Bob可以更新它的本地倉庫--把Alice做的修改拉過來(pull): ~~~ $ git pull ~~~ 如果Bob從Alice的倉庫克隆(clone)，那么他就不需要指定Alice倉庫的地 址；因為Git把Alice倉庫的地址存儲到Bob的倉庫配庫文件，這個地址就是 在git pull時使用： ~~~ $ git config --get remote.origin.url /home/alice/project ~~~ (如果要查看git clone創建的所有配置參數，可以使用"git config -l",?[git config](http://www.kernel.org/pub/software/scm/git/docs/git-config.html)?的幫助文件里解釋了每個參數的含義.) Git同時也保存了一份最初(pristine)的Alice主分支(master)，在 "origin/master"下面。 ~~~ $ git branch -r origin/master ~~~ 如果Bob打算在另外一臺主機上工作，他可以通過ssh協議來執行"clone" 和"pull"操作： ~~~ $ git clone alice.org:/home/alice/project myrepo ~~~ git有他自帶的協議(native protocol),還可以使用rsync或http; 你可以點 這里?[git pull](http://www.kernel.org/pub/software/scm/git/docs/git-pull.html)?看一看更詳細的用法。 Git也可以像CVS一樣來工作：有一個中心倉庫，不同的用戶向它推送(push) 自己所作的修改；你可以看看這里：?[git push](http://www.kernel.org/pub/software/scm/git/docs/git-push.html)[gitcvs-migration](http://www.kernel.org/pub/software/scm/git/docs/gitcvs-migration.html). ## 公共Git倉庫 另外一個提交修改的辦法，就是告訴項目的維護者(maintainer)用?[git pull](http://www.kernel.org/pub/software/scm/git/docs/git-pull.html)?命令從你的倉庫里把修改拉下來。這和從主倉庫"里更新代碼類似，但是是從 另外一個方向來更新的。 如果你和維護者(maintainer)都在同一臺機器上有帳號，那么你們可以互相從對 方的倉庫目錄里直接拉(pull)所作的修改；git命令里的倉庫地址也可以是本地 的某個目錄名： ~~~ $ git clone /path/to/repository $ git pull /path/to/other/repository ~~~ 也可以是一個ssh地址： ~~~ $ git clone ssh://yourhost/~you/repository ~~~ 如果你的項目只有很少幾個開發者，或是只需要同步很少的幾個私有倉庫， 上面的方法也許夠你用的。 然而，更通用的作法是維護幾個不同的公開倉庫(public repository). 這樣可以把每個人的工作進度和公開倉庫清楚的分開。 你還是每天在你的本地私人倉庫里工作，但是會定期的把本地的修改推(push) 到你的公開倉庫中；其它開發者就可以從這個公開倉庫來拉(pull)最新的代碼。 如果其它開發者也有他自己的公共倉庫，那么他們之間的開發流程就如下圖 所示： ~~~ you push your personal repo ------------------> your public repo ^ | | | | you pull | they pull | | | | | they push V their public repo <------------------- their repo ~~~ ## 將修改推到一個公共倉庫 通過http或是git協議，其它維護者可以抓取(fetch)你最近的修改，但是他們 沒有寫權限。這樣，這需要將本地私有倉庫的最近修改上傳公共倉庫中。 譯者注: 通過http的WebDav協議是可以有寫權限的,也有人配置了git over http. 最簡單的辦法就是用?[git push](http://www.kernel.org/pub/software/scm/git/docs/git-push.html)命令 和ssh協議; 用你本地的"master" 分支去更新遠程的"master"分支，執行下面的命令: ~~~ $ git push ssh://yourserver.com/~you/proj.git master:master ~~~ 或是: ~~~ $ git push ssh://yourserver.com/~you/proj.git master ~~~ 和git-fetch命令一樣git-push如果命令的執行結果不是"快速向前"(fast forward) 就會報錯; 下面的章節會講如何處理這種情況. 推(push)命令的目地倉庫一般是個裸倉庫(bare respository). 你也可以推到一 個簽出工作目錄樹(checked-out working tree)的倉庫，但是工作目錄中內 容不會被推命令所更新。如果你把自己的分支推到一個已簽出的分支里，這 會導致不可預知的后果。 在用git-fetch命令時，你也可以修改配置參數，讓你少打字:)。 下面這些是例子: ~~~ $ cat >>.git/config <<EOF [remote "public-repo"] url = ssh://yourserver.com/~you/proj.git EOF ~~~ 你可以用下面的命令來代替前面復雜的命令: ~~~ $ git push public-repo master ~~~ 你可以點擊這里:?[git config](http://www.kernel.org/pub/software/scm/git/docs/git-config.html)，查看remote..url, branch..remote, 和remote..push等選項的解釋. ## 當推送代碼失敗時要怎么辦 如果推送(push)結果不是"快速向前"(fast forward),那么它 可能會報像下面一樣的錯誤： ~~~ error: remote 'refs/heads/master' is not an ancestor of local 'refs/heads/master'. Maybe you are not up-to-date and need to pull first? error: failed to push to 'ssh://yourserver.com/~you/proj.git' ~~~ 這種情況通常由以下的原因產生： ~~~ - 用 `git-reset --hard` 刪除了一個已經發布了的一個提交，或是 - 用 `git-commit --amend` 去替換一個已經發布的提交，或是 - 用 `git-rebase` 去rebase一個已經發布的提交.　 ~~~ 你可以強制git-push在上傳修改時先更新，只要在分支名前面加一個加號。 ~~~ $ git push ssh://yourserver.com/~you/proj.git +master ~~~ Normally whenever a branch head in a public repository is modified, it is modified to point to a descendant of the commit that it pointed to before. By forcing a push in this situation, you break that convention. Nevertheless, this is a common practice for people that need a simple way to publish a work-in-progress patch series, and it is an acceptable compromise as long as you warn other developers that this is how you intend to manage the branch. It's also possible for a push to fail in this way when other people have the right to push to the same repository. In that case, the correct solution is to retry the push after first updating your work: either by a pull, or by a fetch followed by a rebase; see the next section and?[gitcvs-migration](http://www.kernel.org/pub/software/scm/git/docs/gitcvs-migration.html)?for more.