1.两人协同
以主角A和B为例，
- A着手开发test库，并用git管理；
- A邀请B参与test库；
- B通过克隆局域网中的A的test库
B> cd work
B> git clone A@192.168.0.7:~/work/test test
git-clone可利用各种网络协议访问远端机器中的Git仓库,从中导出完整的工作树到本地。
B通过SSH协议访问了A机器上的A账户的test仓库并进行导出,从而在当前目录下建立了test工作树,克隆的仓库名默认原仓库名，所以最后一个test可以省略。
如远端仓库地址 match 账户@IP:工作树路径 git clone使用SSH协议。
- A、B各自对各自机器上的test仓库进行修改、提交。
- 当需要合并时，一般在主要开发者A机器上进行合并，（但同一项目的不同仓库地位均等）。A需要合并B的工作，执行以下git pull：
> cd ~/work/test
> git pull B@192.168.0.5:~/work/test
在A的test仓库中完成对B机器上的test仓库的合并。
git-pull命令可将属于同一项目的远端仓库与同样属于同一项目的本地仓库进行合并.它包含了两个操作：
1).从远端仓库中取出更新版本
2).然后合并到本地仓库。
如果A与B是对了不同的文件进行了改动，那么可以不费周折地完成仓库合并。但是倘若二人对一些相同的文件进行了改动，那么在合并时必然会遭遇合并冲突的问题，此时手动修改发生合并冲突的文件，然后将结果提交到本地仓库。
2.解决冲突
虽然A与B是对同一份文件进行了修改，但是他们的修改并未重叠。现在假设二人对同一文件的同一行做出了修改，那么在仓库合并时会发生冲突，举个栗子，初始foo.txt如下：
one
two
three
A将foo文件的第一行改为大写，B在foo文件第一行加了大写，发生冲突，合并之后的foo文件如下：
<<<<<<< HEAD:foo
ONE
=======
one ONE
>>>>>>> 1116d3270764d91a25532a753a47b8b0e1b6f1b8:foo
two
three
以一串<+HEAD开头和一串>+版本号结束的字串表示冲突部分，而正文第一行ONE表示A的修改结果，中间用了一串=号将二人修改结果隔开，后面一行表示B的当前项目版本对foo.txt的修改结果。
而后主研A可根据现实情况将冲突解决掉，即修改冲突部分，手动选择保留哪一个结果，并删除其他部分，最后将合并处理结果提交到仓库。
3.多人协同
若还有C、D加入这个项目，他们也需要克隆一份项目仓库，然后修改提交，最后由A一一取回BCD三人的仓库，在合并完成一个协同周期。这样导致A的合并处理负担太重，可以分摊到其他人。
Git提供了git-pull的对偶命令:git-push。git-pull命令负责从远端仓库取回版本更新，而git-push可将本地版本更新推送到远端仓库中。
BCD的工作流程
$ git clone A@192.168.0.7:~/work/test
...项目开发...
$ git add改动的文件
$ git commit
$ git pull
...解决版本合并问题...
$ git push
BCD等人需要克隆一份，然后进行开发和本地版本管理，然后从A（或服务器）取得团队最新版本，然后与本地的进行合并，最后推送到A（服务器）。
4.多人协同优化
上个栗子中，A是个项目参与人，但与其他人员又具有相当大差距，因为A的电脑起到了服务器的汇总功能，所以他不需要pull或者push，这样的特权不合理。这里的方案是将汇总的仓库建立在另外的服务器上。
