当你进入一个团队开发时，或许这个团队使用的是基于Git的迭代开发。
Git的安装这里就不说了，主要讲讲几种基于Git的常用的开发模式。
一般我喜欢会设置Git的alias，这样每次输入命令的时候可以少打些字母，同时还能减少拼写的错误。例如：
git config --global alias.st status ==>> git st
git config --global alias.co checkout ==>> git co
git config --global alias.br branch ==>> git br当团队成员给你一个git仓库地址后，并赋予你developer access权限后，那么你可以直接从这个项目地址将代码克隆下来.
git clone git://github.com/sample/sample.git这个时候既然你拥有了access权限，那么你是可以的直接向这个仓库推送代码的。当然了，你不会直接在master分支上进行开发，你可能会新建一个属于自己的分支xl-dev:
git co -b xl-dev
每次对于你这个分支作出修改完后，而且此时master分支没有其他任何变化,此时你可以切换到master分支上，将你修改后的分支代码合并到master分支上
git co master
git merge xl-dev
注意在切换分支前，需要对于你在xl-dev分支下作出的修改，添加到工作区内,避免切换分支时，git阻止你的行为:
git add .
git commit -m 'fix the xxxx bug'如果xl-dev分支你不再需要的时候，即可删除这个分支:
git br -D xl-dev如果你在xl-dev分支下进行开发的过程中,需要进行其他的开发工作，你可能会从master分支下再次新建一个xl-fix分支，并合并到了master分支下了。如果你修改的文件当中不存在公共文件，那么可以顺利的将你的代码合并到master分支上。但是，如果都修改了公共的文件，这个时候去合并的时候就会发生confict,例如webstorm就直接提供了merge confict的功能选项，这个时候需要你手动去合并代码，哪些是aceept yours,哪些是aceept theirs。流程图见下。
解决了冲突后，可以使用
git st 来查看文件的修改状态。
以上是你在本地进行一系列的分支开发工作，但是你在每次在本地开发完后需要将代码推送到远程的服务器上。
每次当你从远程仓库克隆代码下来后，本地会保存一份origin/master的指针，它是你克隆代码时，远程仓库origin的master分支的指针。你在本地是无法对origin/master进行修改的。当你将本地的分支合并到本地的master分支后，origin/master指针的位置是落后于你合并后的master指针的。这个时候当你想往仓库推送代码前，需要将origin/master的代码拉到本地进行合并后，才能向远程服务器推送代码
git fetch originfetch代码的动作是同步远程服务器上的数据到本地，从上面获取你所没有的数据，然后更新本地的代码仓库，将本地代码库的origin/master指针移动到新的位置。
然后将master分支和你的开发分支xl-dev合并,并完成远程代码仓库的推送工作:
git push origin(远程仓库名) xl-dev(本地需要上传的分支名):xl-dev(推送到远程仓库后分支的命名)有时候，你需要接替其他同学的分支进行开发，那么可以直接从远程仓库的分支中新建一个分支后继续开发
git co -b xl-dev origin/xl-dev即从远程仓库的xl-dev分支下新建一个分支后继续开发。
有时，你没有对于项目仓库的develop access，那么这个时候你需要fork一个原始仓库到你的远程仓库地址中，然后从你自己的远程仓库中clone一份代码到本地。
git remote
origin输入此命令查看remote仓库，此时你仅仅和你的远程仓库地址有关联。当然这是不行的，因为原始仓库代码发生了任何变化你都无法感知，这个时候你还需要添加一个上游仓库，就是原始仓库:
git add remote remoteStore ....url....再次输入
git remote
orgin
remoteStore关联原始仓库后，每当你在本地完成了xl-dev的开发工作后，需要提PR给原始仓库合并到master分支前，需要：
git fetch remoteStore这样获取了原始仓库中所有的数据，接下来你需要将remoteStore/master分支和你本地的xl-dev分支进行合并，并解决冲突，然后完成本项工作后，将代码推送到你的远程仓库中，并发出PR.
参考资料:
