工作仓库，就叫做 repo 吧。平时大家都是通过 pull request 合并代码。每个 pull request 都会 squash merge 。
几个月前开了个 feature branch，是给新平台重构用的，就叫做 branchNew 吧。
本来的计划是，每周从 master 分支把新修改同步到 branchNew，这样开发的人继续在 master 上工作，新平台的工作人员在 branchNew 上工作，等要切换的时候，直接用 branchNew 换掉 master 。
因为所谓的"新平台"其实是从一个云服务商换到另外一个云服务商，所以业务代码变动很小，都是一些和 infra 联系紧密的东西，一直以来相安无事。
这事儿本来不归我管，今天发现 branchNew 发布出来的代码出了很奇怪的问题。看了下发现问题大了。然后发现做同步的老哥 X 是这么干的
- 假设这周有 10 个 pull request 合并到 master
- 老哥从 branchNew 开了个新分支 branchNew-for-merge
- 合并来自 master 的 10 个新 commit
- 创建一个新 pull request，从 branchNew-for-merge 到 branchNew
- 然后 squash merge ！！！！没错，squash merge
这样一来，随着时间推移，branchNew 上的代码慢慢都变成老哥 X 写的了。这还没啥。但是发现会出现即便没有 conflict，但是较老的代码覆盖了较新的代码。
原理我没大搞明白
- 因为 master 上代码都是一个 PR 对应一个 commit
- 合并分支每周都做。所以 branchNew 上进来的 master 代码都是新代码
- 没有 conflict
感觉怎么样都是应该新的 commit 会进来，没道理有老的修改去覆盖新修改的事情。因为 commit 的时间线决定了 commit 在时间上的顺序性。
不过无论如果目前的做法是不对了，老哥 X 这样同步已经做了几个月。现在除了砍掉重新同步以外，还有救吗。
Select Language