工作仓库,就叫做 repo 吧。平时大家都是通过 pull request 合并代码。每个 pull request 都会 squash merge 。
几个月前开了个 feature branch,是给新平台重构用的,就叫做 branchNew 吧。
本来的计划是,每周从 master 分支把新修改同步到 branchNew,这样开发的人继续在 master 上工作,新平台的工作人员在 branchNew 上工作,等要切换的时候,直接用 branchNew 换掉 master 。
因为所谓的"新平台"其实是从一个云服务商换到另外一个云服务商,所以业务代码变动很小,都是一些和 infra 联系紧密的东西,一直以来相安无事。
这事儿本来不归我管,今天发现 branchNew 发布出来的代码出了很奇怪的问题。看了下发现问题大了。然后发现做同步的老哥 X 是这么干的
这样一来,随着时间推移,branchNew 上的代码慢慢都变成老哥 X 写的了。这还没啥。但是发现会出现即便没有 conflict,但是较老的代码覆盖了较新的代码。
原理我没大搞明白
感觉怎么样都是应该新的 commit 会进来,没道理有老的修改去覆盖新修改的事情。因为 commit 的时间线决定了 commit 在时间上的顺序性。
不过无论如果目前的做法是不对了,老哥 X 这样同步已经做了几个月。现在除了砍掉重新同步以外,还有救吗。
1
Pipecraft 2021-09-25 11:41:57 +08:00
肯定还有救。就看你想要的结果是什么样子的了。
branchNew 上的修改结束了吗?修改内容代码变动很小对吧? 如果是的话,应该把 branchNew 上的修改 squash merge 成一个 commit,然后和 master 的历史记录合起来。 如果以后不用 master 分支,要切换到新的分支作为主干( branchNew 看来不能作为主干了), 可以先从 master 分支复制出一份分支,叫 main 。 然后把 branchNew 分支 squash merge 到 main,这样这位老哥 X 写的代码会变成一个 commit 在 main 分支的历史记录里。branchNew 现在已经有 master 的新代码也没关系,没有过 conflict,所以和 main 合并时不会有问题。 以后新平台的开发在 main 分支开新分支修改,然后再 squash merge 到 main 。 |
2
msg7086 2021-09-25 11:42:25 +08:00
换个懂 Git 的人来重做一下历史吧……
|
3
AntiGameZ OP @Pipecraft branchNew 修改还没结束,估计还得持续 1 个月样子。所以这就比较麻烦了。
我现在倾向于: branchNew 不要了。因为只属于 branchNew 的修改不多,可以单独提出来。重新从 main 开个 branchGood 出来。然后把只属于 branchNew 的 change cherry pick 进去 但是是第一次碰到这种情况,实在是头大,感觉怎么做都是奇奇怪怪的。而且也不大明白为什么会出现没有 conflict,自动 merge 选择用老代码覆盖了更新的修改。 |
4
passerbytiny 2021-09-25 14:34:03 +08:00 via Android
压缩合并是会丢失历史记录的,你这个 branchNew 压缩合并一次,就丢失它背后 master 上的 PR 记录,经过这么多次压缩合并,已经跟 master 没有任何关系了。
时间太长,完全没救了。你只能删除了 branchNew 分支然后通过本地文件比较再建一个新的分支来折中修补,这会丢失之前 branchNew 分支自身的所有历史记录。 压缩合并跟 SVN 提交是一样的,是单分支新提交而不是对分支合并,压根不存在冲突问题(请注意 SVN 的冲突发生在更新时而不是提交时),自然会产生代码覆盖问题。 压缩合并是处于兼容原因才留下的合并方式,非兼容原因应当禁止使用。要保持线性提交历史,可以采用变基合并。 |
5
AntiGameZ OP @passerbytiny 解释的好,受教了。
|