Learn git notes from xiaobai
the fifth day
多人协作：
首先解决一下上上次笔记中的问题，对于为什么要有一个服务器24小时开机的问题，下面是我室友的回答，怎么说呢，可以说是准准确确明明白白的解答了我的困惑点。
服务器其实就是一个运行了“服务器程序”的设备，这个“服务器程序”当前有很多，但其实就是从网络端口获取输入，处理输入后把它再输出到端口的一个程序；所以其实你自己写一个处理输入和输出的程序，把它的输入和输出重定向到网络端口也能当服务器用，那如果运行着这个程序的设备关机了，谁来处理这些从端口过来的输入呢。
好，室友的回答以疑问句结束，但是我的问题画上了圆满的句号。
git remote -v：查看版本库信息
git push 远程库名 分支名：推送分支到远程库
抓取分支：
git pull：抓取远程分支到本地
注：1.pull之前需要本地和远程分支建立连接：git branch --set-upstream-to=origin/dev dev
2.pull之前当前分支需要提交。
3.pull之后会产生冲突需要修改后提交。
4.以上都是因为pull在抓取到远程分支后会自动合并，而此时可能你的同伴已经推送过他的修改，所以会产生冲突而导致的问题。
简单总结一下多人协作的流程：
1.首先，push自己的修改。
2.如果推送失败，是因为远程分支比你本地的新，需要pull。
3.如果提示no tracking information，则需要通过命令将本地分支和远程分支连接。
4.如果pull冲突，解决冲突提交。
Rebase（变基）：
一种合并代码的方式：和merge相比较
我们假设这样一种情况：
master分支结点：c1<--c3<--c4
dev分支节点：c1<--c2<--c5
如果采用merge方法合并得到的提交历史：
c1<--c2<--c3<--c4<--c5<--c6（因为产生冲突，手动处理后再次提交增加结点6）因为merge是参照时间先后顺序的。
而采用git rebase master方法产生的提交历史为：
c1<--c3<--c4<--c2<--c5因为合并之前解决冲突后add到暂存区就可以，然后执行git rebase --continue继续合并。
最后，rebase命令相比merge就是起到了改变分支为直线，方便其他人查看提交历史，但是如果互相没有商量好，随意使用merge和rebase可能反而起反作用。
好了今天就到这。