文章目录
- Feature分支
- 多人协作
- 推送分支
- 抓取分支
- Rebase
Feature分支
每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
多人协作
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
要查看远程库的信息，用git remote：
git remote
输出：
origin
或者git remote -v显示更详细的信息
git remote -v
输出：
origin git@github.com:XueToWei/XueToWei.git (fetch)
origin git@github.com:XueToWei/XueToWei.git (push)
上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。
推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
git push origin master
并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
-
master分支是主分支，因此要时刻与远程同步； -
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步； - bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
- feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
抓取分支
因为小伙伴的最新提交和自己试图推送的提交有冲突，解决办法也很简单，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
如果git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
git branch --set-upstream-to=origin/dev dev
输出如下：
Branch 'dev' set up to track remote branch 'dev' from 'origin'.
再pull：
git pull
因此，多人协作的工作模式通常是这样：
- 首先，可以试图用
git push origin <branch-name>推送自己的修改； - 如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并； - 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用
git push origin <branch-name>推送就能成功！
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name。
Rebase
Git有一种称为rebase的操作，有人把它翻译成“变基”。
rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。
git rebase # 把分叉的提交历史“整理”成一条直线
rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。
