Git 分支管理策略【重要】

双十节前夕将不同分支间 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 之后

• Why did my Git repo enter a detached HEAD state?

When HEAD is detached, commits work like normal, except no named branch gets updated. (You can think of this as an anonymous branch.)

• A Visual Git Reference；