Git flow
git-flow 分支模型由五条规则和一大堆记账工作组成。规则很简单；人们在发布日傍晚六点搞砸的，是那些记账——把一个热修复合进了 main 却忘了 develop，或者给错误的分支打了标签。
⌘K → Git flow 帮你记这笔账。
这套布局
| 分支 | 承载 |
|---|---|
已发布分支（main） |
生产环境里跑的东西。每次发布都在这里打标签。 |
集成分支（develop） |
两次发布之间已完成工作的汇聚处。 |
feature/* |
一个工作单元，从 develop 开出。 |
release/* |
正在稳定中的某个版本，从 develop 开出。 |
hotfix/* |
一个紧急修复，从 main 开出——生产环境等不了 develop。 |
Gitcito 读写的是 git flow 命令行工具所用的同一批 gitflow.* git 配置键（gitflow.branch.master、gitflow.prefix.feature，……）。别人已经跑过 git flow init 的仓库会被立刻识别，而在这里配置好的仓库之后也能配合命令行工具使用。Gitcito 全程只运行普通的 git 命令——不需要安装那个命令行工具。
设置会写入那些键，并且在集成分支尚不存在时，从已发布分支创建它。除此之外什么都不动。任何名字或前缀之后都可以在编辑布局里改。
开始
选一种类型，输入一个名字，按开始。在你真正落定之前，对话框会显示它即将创建的分支，以及它将从哪个分支创建：
feature/search from develop
hotfix/1.0.1 from main
名字是你输入的；前缀来自布局。
结束
结束才是值得自动化的那一部分，因为它是好几个必须全部发生的步骤：
| 类型 | Gitcito 做的事 |
|---|---|
| 特性 | 用 --no-ff 合并进 develop，删除该分支，把你留在 develop 上 |
| 发布 | 合并进 main，打标签，合并进 develop，删除该分支，把你留在 develop 上 |
| 热修复 | 合并进 main，打标签，合并进 develop，删除该分支，把你留在 main 上 |
--no-ff 是刻意的：正是那个合并提交让这个分支在事后仍能在图里看得见。没有它，一个短命的特性分支会消失成一条直线，这个模型也就失去了它存在的意义。
标签是 <版本标签前缀><名字>——用默认前缀时，release/1.1.0 会变成 v1.1.0。取消勾选给发布打标签可以跳过它；如果你想要的不只是默认内容，可以写一条标签信息。
它拒绝做的事
- 工作区不干净就会中止。 先提交或贮藏；结束操作会合并两个分支并两次移动 HEAD，围着未提交的工作做这件事，正是人们把它弄丢的方式。
- 合并发生冲突会把整件事回滚。 如果合并进 main 成功了，但合并进 develop 冲突了，你本来会剩下一个做了一半的发布。Gitcito 会把每个分支恢复到原来的位置，并报告这个冲突。手动合并那个分支，在冲突解决器里解决它，剩下的流程就由你自己手动完成。
- 它从不推送。 结束是本地的。等你准备好了，再推送 main、develop 和那个新标签——见同步。
撤销
一次撤销就能把一切放回去：两个分支都回到它们之前的提交，标签被删除，被结束掉的分支在它原来的顶端重新创建。这正是「结束」值得放心一试的全部理由。
什么时候不该用它
git flow 适合有版本化发布、并且维护着一个受支持的生产分支的软件。如果你一天从 main 部署好几次，那么发布分支和热修复分支就是你不会用到的仪式感——堆叠分支或者从 main 开出的普通短命分支更合适。这个模型里关于特性分支的那一半，单独用起来仍然很好。