两个分支互相 merge 之后,代码会变成一样的么?

场景:

隔壁部门老项目,有 dev 和 test 分支.test 分支应该/也许/大概是基于 dev 创建的(时间太久了看不太清楚...) 由于一些历史原因,某段时间 dev 和 test 分支居然同时有代码提交. 现在想重新把 git 规范搞起来,严格按照 dev>test>master 这种方式.

两个方案:

1.dev 向 test 合并,再删掉 dev,然后基于 test 创建 dev 分支.后续按标准规范来.

2.dev 向 test 合并,然后 test 向 dev 合...后续按标准规范来.

我觉得 1 比较正常.但是最终不知道是怕代码丢了还是啥的,居然用的方案 2...

这种 A 和 B 互相 merge 的操作我也没见过..这是做了个啥???

ztxcccc

2023-11-27 14:41:12 +08:00

用以下指令可以看到所有的不同之处，或者交换分支名
git diff dev..test >> diff

merge 里有 commit 号，被 merge 过的 commit 不会被再次 merge

Rache1

2023-11-27 14:52:01 +08:00

> 这种 A 和 B 互相 merge 的操作我也没见过..这是做了个啥???

A:master ，B:feature-01

以这种为例的话，正常情况下 B 开发完成了，就合并到 A 。这是理想情况，但是实际情况会比较复杂，比如 A 新合并了 C 的内容。那么现在 A 就领先于 B 了，这时候如果 B 和 C 修改了同一部分内容。你在想把 B 合并到 A 的时候，就会有冲突了。

面对这种情况，就会出现 A 合并 B ，解决冲突，然后 B 再合并到 A 了。

简单的说，就是你的目的是要把功能合并到主干，但是主干又有新的代码，你可以把主干上最新的代码合并到你的功能分支上，这也就是最终会合并到主干上的效果。

CrazyMonkeyV

2023-11-27 15:03:32 +08:00

肯定是按照第二种来呀。2 楼已经说了原因了。而且分支管理，正常来说，没有删除主分支的习惯。
我们的版本管理是：
比如当前版本是：1.1.0 ，那么每个人都要切到自己临时分支，如：name-1.1.0 。然后在上面做修改，改完后，合并到 1.1.0 。在 1.1.0 测试完成发布后，就封版了。下次就是 1.3.0 了。

Felldeadbird

2023-11-27 15:51:47 +08:00

其实你 2 个方案合并，他们肯定会有一次冲突产生的。解决了冲突，两个分支其实就是同一个内容（后续按照规范执行的话）。

然后为什么怕丢代码，文件之类问题呢？两个差异大的分支合并肯定会保冲突的，只要解决冲突的人没合并错，就不会丢代码，丢文件。我用了 10 年 git ，没出现过这个问题。

paceewang1

2023-11-28 10:22:28 +08:00

@xubingok
@Rache1

两个分支互相合并也有可能不一样的吧，要看两个分支的不一样还是要用 diff ；但是两个分支互相合并，是很正常的操作：A release B feature
当你的 feature 修改完成，要放到测试环境的时候，期间有可能别的同事已经更新了 release 发版了，为了保证基准测试，你得 B merge A 吧？
当你得 feature 上线，是不是得 A merge B 。

Rache1

2023-11-28 13:40:04 +08:00

@paceewang1 #10 基于 Git 特性，这显然是可能的，多人协作的时候其他人可能在任何时候提交新的代码到公共分支。

这里只是说在本地经过相互合并后，两个分支已经是一样的了。

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/995585

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.