git: 推荐的 Git 分支管理策略

[Liam0205]

参见：http://www.ruanyifeng.com/blog/2012/07/git.html

推荐使用。

[inkydragon]

把这套策略结合实际，我的理解就是：

• mater 分支
  主要接受其他分支的merge，用于 release。不直接提交commit到主分支。
• release 分支
  个人感觉没什么必要？需要放出试读版可以考虑打上prerelease标签
• dev 分支
  主要提交commit的分支，也用于合并外来的pr。
• (临时的)fixbug 分支
  暂时想不到应用的场景，预计用不上。一般来说翻译完都会编译看一下，基本不会出什么bug。
  如果要改模板，小改动不成问题，编译一下也能发现bug; 大改动就开feature分支吧。
• (临时的)feature 分支
  对使用TeX的书籍来说，用于改模板挺好，当然是比较大、效果不确定的改动才有必要新开分支。

[Liam0205]

简单来说，master 是对外的稳定版本，dev 是对内保存阶段性工作的开发版本，feature-xxx/dev-xxx 是集中开发某个功能的版本，hotfix-xxx 是快速修复某些发现的问题的版本。前两个是持续存在的分支，后两个都是完成使命后应当删除的分支。

• master：接受其它分支 merge，包括 dev 和 hotfix 分支；不直接提交到 master 分支。
• dev：接受其它分支 merge，包括 hotfix 和 feature 分支；不直接提交到 dev 分支。在阶段性翻译完成后（例如翻译完成一个新的章节），merge 到 master 分支。
• hotfix-xxx：翻译过程发现一些问题，比如 字体名称翻译 #2 提到的问题就是从 master 签出 hotfix 分支解决问题后，分别 merge 到 master 和 dev 分支上去；而后删除分支。
• feature-xxx/ dev-xxx：翻译过程的主力分支。例如翻译第四章时，从 dev 分支签出名为 dev-chapter04 的分支，在其上进行翻译工作。一段时间（比如翻译了一个上午、一天）后，向 dev merge 修改；之后可在分支上直接继续翻译。当翻译完成后，向 dev 分支 merge 修改后删除分支。

所有的 merge 操作，都建议使用 --no-ff 参数，以方便追溯历史流程。

[inkydragon]

再加一条如何：像比较短的章节可以一次性翻译完直接提交到dev，没必要单开分支

虽然没剩几篇了。

[Liam0205]

这个应该没问题吧，短小精悍的章节一两次提交就足够了，不至于引起混乱。

[inkydragon]

关于这个issue: 可以一直开着。或者继续开一段时间，看看还有没有什么需要补充的，然后关掉issue,有需要时再重启。另：可以把共识整理一下，单独成页放到wiki里