介绍#

产品团队在产品研发以及和社区互动时，使用目前流传最广的 Git 分支管理规范 gitflow 。
gitflow 主要流程如下图：

Branch（分支）#

版本库有两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。

• develop：开发分支。日常开发使用的分支，项目协作者主要工作在这个分支上，同时所有的 pull request 都应该发到这个分支；

• master：主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

其实，常设分支只需要这两条就够了，不需要其他了。但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：

• feature branches：功能分支。它是为了开发某种特定功能，从Develop分支上面分出来的，开发完成后，要再并入Develop。功能分支可以有多个，这些分支通常只是个人使用，存在开发者本地库中，如果需要多人协作，则需要推送到远程仓库；

• release branches：预发布分支。它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试，并允许修正小问题；

• hotfixes：补丁分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。补丁bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。

Tag（标签）#

• Tag: 对应每个发布版本的版本标识。

app-design 的 tag 命令规范遵照 Semantic Versioning 2.0.0 语义化版本规范。

新功能开发流程#

对于开发过程中的不同任务，需要在对应的分支上进行工作并正确地进行合并。每个任务开始前需要按照指定的步骤完成分支的创建。例如当需要开发一个新的功能时，基本的流程如下：

• 从 develop 分支创建一个新的 feature 分支，如 feature/my-awesome-feature。

• 在该 feature 分支上进行开发，提交代码，如需多人协作，push 到远端仓库。

• 当代码完成之后，合并到 develop 分支并删除当前 feature 分支。

版本发布流程#

当需要发布新版本时，采用的是如下的流程：

• 确保所有要发布的 pull request 都已经 merge 到 develop了；

• 从 develop 分支创建一个新的 release 分支，如 v1.1.0；

• 把 release 分支部署到持续集成服务器上进行测试。测试包括自动化集成测试和手动的用户验收测试；

• 对于测试中发现的问题，直接在 release 分支上提交修改。完成修改之后再次部署和测试；

• 当 release 分支中的代码通过测试之后，把 release 分支合并到 develop 和 master 分支，并在 master 分支上添加相应的 tag。

打补丁流程#

打补丁是指对提供给用户使用的正式版本进行修复。

• 从 master 分支创建一个补丁分支；

• 修补结束后，合并到 master 分支并打 Tag；

• 再合并到 develop 分支；

• 最后，删除补丁分支。 并非每个 bug 都有打补丁的必要，对于不紧急的 bug，可以在 develop 里修复后随下一个版本发布。

关于git-flow的详细信息，你还可以参考 git-flow 备忘清单

Git 客户端工具#

虽然 eclipse、webstorm 之类的 IDE 都自带 Git 客户端，但是我们仍然向你推荐更好用的 SourceTree，而且 SourceTree 默认已经集成了 gitflow 的扩展，用起来更方便。

你可以参考 SourceTree 工具的使用

commit 代码#

在 commit 的注释中关闭 issue#

你可以在提交消息中包含关键字，以自动关闭Git中的issue。

要在同一个存储库中关闭一个问题，请使用下面列表中的一个关键字，然后引用提交消息中的问题编号。 例如，当提交合并到默认分支中时，具有Fixes＃45的提交消息将关闭该存储库中的问题45。

如果提交处于非默认分支中，则问题将保持打开，并且将使用提示引用该问题。 如果提交被强制推送到默认分支并且已经存在于另一个分支上，则该问题将保持打开。

关闭issue的关键字：#

• close

• closes

• closed

• fix

• fixes

• fixed

• resolve

• resolves

• resolved

参考 gogs 这个 issue 或者 github的帮助。