承接后续——————————
推送
当自己一个人进行开发时，在功能完成之前不要急着创建远程分支。
拉取
请读张文钿所写的《使用 git rebase 避免無謂的 merge》。
合并
在将其他分支的代码合并到当前分支时，如果那个分支是当前分支的父分支，为了保持图表的可读性和可追踪性，可以考虑用 git rebase 来代替 git merge；反过来或者不是父子关系的两个分支以及互相已经 git merge 过的分支，就不要采用 git rebase 了，避免出现重复的冲突和提交节点。
Git 的一大特点就是可以创建很多分支并行开发。正因为它的灵活性，团队中如果没有一个成熟的分支模型的话，那将会是一团糟。
分支模型
有个很成熟的叫「Git Flow」的分支模型，它能够应对 99% 的场景，剩下的那 1% 留给几乎不存在的极度变态的场景。
需要注意的是，它只是一个模型，而不是一个工具；你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。
简单说来，Git Flow 就是给原本普普通通的分支赋予了不同的「职责」：
- master——最为稳定功能最为完整的随时可发布的代码；
- hotfix——修复线上代码的 bug；
- develop——永远是功能最新最全的分支；
- feature——某个功能点正在开发阶段；
- release——发布定期要上线的功能。
看到上面的「master」和「develop」加粗了吧？代表它们是「主要分支」，其他的分支是基于它们派生出来的。主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个。
