项目地址： https://github.com/MamaShip/MR-Tracker
大家都知道基于 git commit 信息生成 ChangeLog 的工具，我之前也用过 git-chglog 等。
后来发现小团队内统一 commit 规范实在是费力不讨好……尤其有些提交很零碎，commit 信息作为 changelog 太琐碎，强制大家整理成完整提交再合入又显得不敏捷。
实际上，在 Github 上，自带的 Generate release note 功能就是基于 Pull Request 来分析的——它只记录真正合入主干的那笔改动，不会把粒度放到 commit 那么细。
所以我就自己写了个 Gitlab 上基于 Merge Request 生成 ChangeLog 的小工具。通过 gitlab API 获取 MR 信息，把版本（tag）间的改动创建成 changelog 。
工作上一直使用git作为代码版本管理工具，但从来没掌握好它。最近我负责的这部分代码管理越来越混乱，掌握一套正确成熟的git工作流程几乎是迫在眉睫的事情。
git 的基础使用就不赘述了。大概每个程序员都会花几个小时掌握 git 的基础操作，再花几周去实践和熟悉吧。
首先推荐两篇文章：
如果你没有遇到过多人协作下代码管理混乱、想要 release 新版时却交不出一份能 work 的代码，读这两篇文章可能不会很有 sense。但你只要遇过一次版本危机，再硬着头皮连续加班到凌晨一两点，回头来看就会很有感受。
上面两篇文章其实讲了2件重要的事：
由于我在一家制造业企业，RD 只需隔一段时间 Release 一个 FW 版本给产线即可。比起敏捷地迭代，版本的稳定性更重要。传统的 git flow 是适合我们的。
在 git flow 框架下，有2个长期分支：
master名为master，却并不是日常工作的基础分支，而是一个经过验证的稳定分支。随时可以用来发布。
与master平行存在，内容几乎相同但又略有超前的，就是develop分支。平日的开发必须基于develop分支进行。在git flow框架下，当一个新的需求产生时，你基于最新的develop拉出一个 feature/xxx 分支，进行开发，功能完成后，再合并回 develop。（合并后 feature/xxx 分支自然消亡）
3种短期分支（完成开发后，合并进长期分支，然后删除）：
feature 只能从 develop 拉出，然后合并进 develop。
hotfix 只能从 master 拉出，然后合并进 master 和 develop。
release 则是从 develop 拉出，进行测试，完成验证后合并进 master。
当 git flow 进行 release 时，它实际做了2件事：把从上一次 release 至今的 develop 改动经过验证后合入 master，再反向把 master 合并回 develop 确保两边同步。
为什么要反向 merge 一遍，因为 release 过程中若测试出一些问题，就可以直接在 release/xxx 分支上进行修改，而这个改动是没有发生在 develop 上的。所以 release 分支在删除时会保证这些改动也被同步到develop。
在这样的设计下，master 是稳定的，它受到 release 规则的保护，除非发生 hotfix，就只有经过测验的 release 分支才能合进 master。
而 develop 分支则相对比较敏捷，根据需求拉出 feature branch 后，开发者可以专注于自己的子任务，把兼容性等全局测试交给 release 分支去负责。
使用 git flow 相关工具，可以帮助规范这个流程。例如，工具会禁止你基于 master 拉出一个新的 feature 分支，因为新 feature 总是应该基于 develop 分支来开发，若要紧急修补某个bug，你应该使用 hotfix。
一些git flow工具（如gitflow-toolkit），还可以规范你的commit，确保commit信息清晰有效，能被script解析。这样你就能使用现成的工具（git-chglog、conventional-changelog），自动生成change log。这在 release 正式版本的时候是很有用的：
以上是我理解的 git flow 实践。在应用中发现它也对使用者提出了一些要求：
git flow 仍在实践中学习。有新的理解会再更新。
Powered by WordPress & Theme by Anders Norén