git使用教程七：多人协作
目录
-
- *多人协作*
- *变基*
多人协作
从远程仓库克隆时。实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称为origin，要查看远程仓库的信息，用git remote
$ git remote
origin
或者更详细的信息，git remote -v
$ git remote -v
origin https://github.com/hyd861001/my_python.git (fetch)
origin https://github.com/hyd861001/my_python.git (push)
可以看到你可以进行推送和抓取的分支，master分支是主分支，因此需要时刻与远程同步，dev分支是开发团队的开发分支，所有团队成员都需要在上面工作所以也需要与远程同步，其他分支没有必要可以不同步。
分支推送的命令为git push origin
$ git push origin master
推送dev分支：
$ git push origin dev
多人协作时，大家都会往master和dev分支上推送各自的修改，加入你的一个小伙伴从远程仓库克隆时，默认情况下你的小伙伴只能看到本地的master分支，现在小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地可以用以下命令
$ git checkout -b dev origin/dev
现在他就可以在dev上修改了，然后push到远程，如果小伙伴在推送的时候而碰巧你也对同样的文件做了修改并试图推送这个时候后推送的就会推送失败，因为推送的两者有冲突，解决问题的方法就是先用git pull把最新的提交从origin/dev抓下来然后在本地合并，解决冲突在推送。
$ git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/ dev
git pull失败了原因是本地dev和origin/dev没有建立连接，根据提示指定链接：
$ git branch --set-upstream-to=origin/ dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.
然后再pull，这样就没有冲突了，然后再手动修改冲突，再推送。
因此，多人协作的工作模式通常是这样：首先，可以试图用git push origin 推送自己的修改；如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；如果合并有冲突，则解决冲突，并在本地提交；没有冲突或者解决掉冲突后，再用git push origin 推送就能成功！如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to origin/。这就是多人协作的工作模式，一旦熟悉了，就非常简单。
查看远程库信息，使用git remote -v；本地新建的分支如果不推送到远程，对其他人就是不可见的；从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；从远程抓取分支，使用git pull，如果有冲突，要先处理冲突
变基
多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。每次合并再push后，分支看上去很乱，有强迫症的童鞋会问：为什么Git的提交历史不能是一条干净的直线？其实是可以做到的！Git有一种称为rebase的操作，有人把它翻译成“变基”
当我们提交推送失败后，按照经验先pull一下，然后合并提交，这样有时会导致提交历史很多分叉，不好看，这个时候变基就派上用场：
$ git rebase
会输出一大堆结果，不管它，没有错误就行，然后用git push把本地分支推送到远程
变基操作会使提交历史变成一条干净的直线。