背景

用 Git 管理代码版本，希望 开发-发布 流程更加规范，至少在多人协作的项目上，需要防止开发时的代码合并问题。

内容

基本知识请参考 Git-Flow 流程，这是到目前为止，最清爽的 Git 操作流程，它并非是全新的技术，但它可以保证你在开发过程中，降低因不规范操作带来的可怕的时间成本。

在 IntelliJ IDEA 中有一个 Git-Flow Plugin，它很好用，但目前几乎没有相关文档来描述如何使用。

当第一次从 IntelliJ IDEA 中安装 Git-Flow Plugin，我非常激动，因为我从此不用在 SourceTree 中浪费大量的时间，以祈求 SourceTree 能够帮我将 Git-Flow 流程执行成功。

对于新手来说，使用 Git-Flow Plugin 会有以下几个困惑：

• 我什么时候开始使用？
  任何时候。只要你的仓库不存在违反 Git-Flow 规范的分支名称，并且你当前的工作空间是干净的（这表示你应该提交所有的本地改动，但无须为此 push 到远程仓库）

• 初始化仓库会带来什么？
  清爽。当你发现 No Gitflow（图1）时，你可以点击它，再选择初始化你当前的仓库（图2）。它会建立一个从 master 分支检出的 develop 分支，并（可能）保证两个分支的代码与远程仓库同步。随后你可以发现更多的操作，比如新的功能、发布、修复（图3）。但在这之前，你必须选择使用默认配置，还是自定义配置（图4。注意，图中的自定义配置与默认配置相同）。

图1
图2
图3
图4

注意：第一个选项是产品发布的分支名称，一般来说，生产环境总是稳定的，我们选择 master 分支；第二个选项是下一次发布开发的分支名称，实际上就是开发分支，只不过当需要发布时，会从这个分支 check out 出来新的发布分支；第三个到第七个无需改动，除非你有特殊的命名嗜好。

• 如果我忘记使用 Git-Flow 怎么办？
  没关系。既然你不喜欢，就卸载它好了。（开个玩笑QAQ）实际上 Git-Flow 只是一种规范，如果你的操作不符合规范，那自然需要花费额外的精力，使仓库回到正规上来。那么你应该仔细研读 Git-Flow，当你精通此道时，或许你并不需要插件来帮你完成规范操作。

提示：空仓库，比如从 GitHub、GitLab、码云等等地方创建的新仓库，你必须先提交一个版本到 master 分支，再进行 Git-Flow Plugin 的初始化。否则，你就必须在初始化之后，从 develop 分支切换到 master 分支，再 push 到远端仓库。这是因为，空仓库没有默认分支，第一个提交并推送上来的分支，就是默认分支。如果你拥有修改默认分支的权限，那对你没有影响，但一般你只有开发权限，这时候你就无法修改仓库设置了。

总结

Git-Flow Plugin 就像工作秘书一样为你服务，你可以放心大胆地干，只要你足够熟练，不用担心“闹出人命”。