Git 分支管理策略
2016-10-10 本文已影响118人
michael_jia
双十节前夕将不同分支间 merge，本地远程 rebase 的适用场景进行了区分，真是一件喜事，基本解决了 Git 分支管理上的一系列策略问题；
本文就简要、集中的陈述一下 Git 分支管理策略；
原则
-
Git の 分支与整合策略；
注意区分 合并 和 变基；整合的两种方式：merge（合并），rebase（变基）；
注意 git pull 命令，既可以是 git fetch + merge 组合，又可以 git fetch + rebase 组合；
当下，我们普遍采用的是 fetch + rebase 组合的 pull； - 在一个迭代分支上协作开发，采用 rebase，实际上是本地分支 rebase 远程分支；
所产生的 log 整洁有序； - 迭代分支从 dev 分支开出；
- 迭代分支应经常 merge dev（git merge dev）；
尤其是在 dev 上 hotfix 的东西在发布后，要及时地 merge 到迭代分支上； - 迭代完成后，dev 合并迭代（git merge 0.8d）；
- 删除迭代分支（git branch -d 0.8c）；
迭代分支 merge dev 时出现冲突怎么办？
- 为了降低冲突概率，请及时 merge dev；
- merge 时出现冲突，解决冲突
# 确保本地库当前代码是你想要的；
git checkout 1.0
git merge dev
# 出现冲突，解决冲突
git add .
git commit -a -m 'merge dev 到 1.0，解决冲突'
git push
如果发生了不幸：比如你在 commit 之后、push 之前 pull 了，就会出现麻烦；如果不明白原理，没有及时中止 rebase，而是选择继续解决出现的新问题，那么你就 误入歧途 了。
-
commit 之后、push 之前 pull出现新问题的原因分析
由于我们 pull 采用的是 fetch + rebase，fetch 操作没有影响（因为远程 origin 1.0 没新 commits），rebase 操作把 merged 过来的 dev 上所做的 commits 基于 origin/1.0 又 applying 了一遍。至于为什么会这样，还不理解。 -
commit 之后、push 之前 pull出现问题后如何解决？
git rebase --abort果断中止 rebase 即可；
何时出现 diverged 情况？
- 新分支 0.8c 从 dev 开出；
- 0.8c 和 dev 各有若干 commits；
- 0.8c：git rebase dev，产生 diverged（和远程分支分叉了）；
- 解决若干冲突，本地 0.8c 和 dev 指向同一个 commit；
- 再无法推送到远程 0.8c（因为 diverged）；
HEAD detached 如何处理？
- peter 晚上在家 2 次提交（C1和C2）：
b26接口和格式化日期，使用同一函数两个 commits；并且 push 到 remote； - peter 翌日公司 1次 提交（C3）：
添加yii2mod-comment（yii2mod/yii2-comments）
提交前没有 pull。 - git pull 后出现：
HEAD detached from refs/heads/v0.8（即 HEAD 指向的是 C2，而本地 v0.8 指向的是 C3，虽然本来她跟踪的是远程 v0.8） - 解决方法
当下处于 * (HEAD detached from refs/heads/v0.8) 状态（当前 HEAD 指向 C2），
git merge v0.8（指向 C2 的 HEAD 将 C3 合并到 HEAD）
git push origin HEAD:v0.8 （将当前本地 HEAD 推到远程 v0.8）
git pull origin v0.8
使用的 git 命令
merge 之后
When HEAD is detached, commits work like normal, except no named branch gets updated. (You can think of this as an anonymous branch.)
