Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

坚决保持 master 分支干净

  我觉得那些描述信息让人完全看不懂的 commit 都不应该合并到 master。特别是一堆 fixup 的 commit。最近老和测试撕逼,因为测试希望自己测试的东西就是将要发布上线的东西,也就是拒绝直接测 feature 分支。而我希望的则是保持 master 的 commit log 干净。
  测试希望在提测之前将把代码合到 master,然后测完 master 直接发布。理由是如果测试 feature 分支,它合并到 master 后可能还会因为合并造成影响,导致测试的版本和合并后的不同。需要重新回归测试一遍,造成额外的工作量。
  对于这种将根本就没测试通过不能发布的东西合并到 master 的做法我是拒绝的。理由有两点,首先是 master 应该保持可以从上面开出可用新分支的状态。如果一坨未经测试的代码被合到 master 就会造成从当前 master 开出的分支是有问题的。另一点是测试过程中会产生 fixup,而 master 是无法 rebase 的,我不希望一堆 fixup 污染了 master 的 commit log。
  为了满足测试的需求并且不污染 master,于是每当有版本需要测试时就从 master 开出 release 分支并将代码推上去(注意是推上去,不是合上去)。测试只测 release 分支,如果测通过则进入发布流程。否则开发在本地修复 commit 并强推回 release 分支上(这是为了避免产生 fixup),直到测试通过。在代码发布后再从 release 分支合并到 master。这样既满足了测试的需求,也不会弄脏 master。
  我无法理解测试不测 feature 分支的用意(其实是懒得找测试撕逼)。如果 feature 分支 rebase 过 master 的话,测完后合并到 master 根本用不着回归测试,因为不可能有任何冲突。
  解决问题有很多方案,上面这个只是其中的一种而已。而且大家使用的 git 工作流也不同,选用的方案肯定也会不同。但无论是何种工作模式,「保持 master 分支干净」这个核心思想是不容动摇的。
网名:
3.84.186.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^