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

[xubingok]

场景:

隔壁部门老项目,有 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]

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

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

[Rache1]

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

A:master ，B:feature-01

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

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

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

[CrazyMonkeyV]

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

[xubingok]

@Rache1
互相合并,且解决冲突后,两个分支代码是不是就是一样的了?

[Felldeadbird]

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

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

[Rache1]

@xubingok #4 是的，A 合并到 B ，解决冲突，B 再合并到 A ，这时候他们两个分支的代码就是一样的了

[wonderl17]

1 这么搞不就是一个人写代码么，多人协作肯定要用 2 啊

[28Sv0ngQfIE7Yloe]

@CrazyMonkeyV

那请问 1.2.0 呢？

[Charrlles]

用 cherry-pick 吧，或者用一个公共的 dev 分支，每个人再从 dev 分支切 dev1 dev2 ，然后定期 rebase 到最新的 dev

[paceewang1]

@xubingok
@Rache1

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

[Rache1]

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

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

[CrazyMonkeyV]

@Morii 万一临时有 BUG 或者需求更改，就 1.2.0 上搞。没问题了再搞会主分支、

[CrazyMonkeyV]

@Morii 万一临时有 BUG 或者需求更改，就 1.2.0 上搞。没问题了再合并回主分支。