团队合作和个人独立工作最大的不同在于你会提交代码别人也会提交你会push别人也会push因此除了把代码上传每个人还需要把别人最新的代码下载到自己的电脑。而且这些工作都是并行进行的因此工作模型很复杂把别人的新提交拿到本地先说一种简单的情况你的同事刚把他写的几个提交push到了中央仓库你怎么把它们取下来。假装同事除非你能要求同事陪你练习 Git否则你只能一人分饰两角时不时地模拟一下同事的操作来达到独自一人做多人项目练习的效果。而为了模拟同事的操作你需要再clone一次中央仓库到本地来当做你模拟同事的本地仓库git clone 仓库地址 git-practice-another注意执行这条之前别忘了先 cd .. 切换到父目录不然你会把新的本地仓库创建在原先的本地仓库的工作目录内。为了目录名称不冲突这次的clone需要加一个额外参数上面那行代码最后的git-practice-another来手动指定本地仓库的根目录名称。在这条指令执行完成后你就有了两个内容相同的本地仓库git add shopping\ list-colleague.txt git commit现在你就可以假装/git-practice这个目录是你的电脑上的工作目录而那个新建的/git-practice-another是你同事的电脑上的工作目录。Git 的管理是目录级别而不是设备级别的也就是说/git-practice目录内的.git只管理/git-practice里的内容/git-practice-another目录内的.git也只管理/git-practice-another里的内容它们之间互不知晓也互不影响。帮同事提交代码并 push 到中央仓库要在你的电脑上把同事的代码取下来首先 GitHub 上要有你同事的新代码也就是说你首先要把同事的代码 push 到中央仓库去。所以第一步切换到同事的目录cd git-practice-another现在到了同事的工作目录你的身份就是你的同事了。帮他写点内容吧嗯看起来不错帮他提交吧提交完成以后push到 GitHubgit push把同事 push 的新代码取下来GitHub 上有了同事的新代码以后你就可以变回自己把「他」刚push上去的代码取到你的仓库了。首先切回/git-practice目录cd ../git-practice然后把同事的代码取下来吧从远程仓库更新内容用的是一个新的指令pull。git pull这时候再看看你的本地目录可以看到同事提交的shopping list-colleagure.txt已经同步到本地了。也就是说现在你的本地仓库和同事的又一致了。多人合作的基本工作模型这就完成了一次简单的合作流程同事commit代码到他的本地并push到 GitHub 中央仓库你把 GitHub 的新提交通过pull指令来取到你的本地通过这个流程你和同事就可以简单地合作了你写了代码commitpush到 GitHub然后他pull到他的本地他再写代码commit,push到 GitHub然后你再pull到你的本地。你来我往配合得不亦乐乎。但是这种合作有一个严重的问题同一时间内只能有一个人在工作。你和同事其中一个人写代码的时候另一个人不能做事必须等着他把工作做完代码push到 GitHub 以后自己才能把push上去的代码pull到自己的本地。而如果同时做事就会发生冲突当一个人先于另一个人push代码这种情况必然会发生那么后push的这个人就会由于中央仓库上含有本地没有的提交而导致push失败。为什么会失败因为 Git 的push其实是用本地仓库的 commits 记录去覆盖远端仓库的 commits 记录注这是简化后的说法push的实质和这个说法略有不同而在远端仓库含有本地没有的 commits 的时候如果push成功将会导致远端的 commits 被擦掉。这种结果当然是不可行的因此 Git 会在push的时候进行检查如果出现这样的情况push就会失败。怎么办下面就说。push 发生冲突在现实的团队开发中全队是同时并行开发的所以必然会出现当一人push代码时中央仓库已经被其他同事先一步push了的情况。为了不让文段显得太过混乱这里我就不带着你一步步模拟这个过程了。如果你希望模拟的话这里是步骤切到git-practice-another去假扮成你的同事做一个commit然后push到 GitHub切回git-practice变回你自己做一个不一样的commit。这个时候远端中央仓库已经有了别人push的commit现在你如果push的话git push从上图中的提示语可以看出来这么长的提示语有人表示不想看由于 GitHub 的远端仓库上含有本地仓库没有的内容所以这次push被拒绝了。这种冲突的解决方式其实很简单先用pull把远端仓库上的新内容取回到本地和本地合并然后再把合并后的本地仓库向远端仓库推送。git pull在上面的文段里已经举过一次git pull的例子但这次的git pull操作并没有像之前的那样直接结束而是进入了上图这样的一个输入提交信息的界面。这是因为当pull操作发现不仅远端仓库包含本地没有的commits而且本地仓库也包含远端没有的commits 时它就会把远端和本地的独有commits 进行合并自动生成一个新的commit而上图的这个界面就是这个自动生成的commit的提交信息界面。另外和手动的commit不同这种commit会自动填入一个默认的提交信息简单说明了这条commit的来由。你可以直接退出界面来使用这个自动填写的提交信息也可以修改它来填入自己提交信息。这种「把不同的内容进行合并生成新的提交」的操作叫做合并它所对应的 Git 指令是merge。事实上git pull这个指令的内部实现就是把远程仓库使用git fetch取下来以后再进行merge操作的。关于更多merge的介绍会在后面介绍。在退出提交信息的界面后这次pull就完成了远端仓库被取到了本地并和本地仓库进行了合并。在这个时候就可以再push一次了。由于现在本地仓库已经包含了所有远端仓库的 commits所以这次push不会再失败git push这样就把push时本地仓库和远端仓库内容冲突的问题解决了。小结多人合作的基本工作模型我们把「多人合作的基本工作模型」进行了改良写完所有的commit后不用考虑中央仓库是否有新的提交直接push就好如果push失败就用pull把本地仓库的提交和中央仓库的提交进行合并然后再push一次到此为止这个工作模型已经是一个最简单的可用的工作模型了。一个小团队如果对版本管理没有什么要求的话这个工作模型已经可以让团队用来合作开发了。但是这种模型由于过于简单所以只能适用于对代码管理没太大需求的开发团队。接下来我将介绍一种基于branch的工作模型很多中小型团队的代码开发都是采用的这种工作模型。