Looker + Git 似乎很容易引起合并冲突

This topic created in 1421 days ago, the information mentioned may be changed or developed.

求问一个版本管理的问题：

三个分支: main, staging 和 dev. 在一开始这三个分支是完全一样的。

第一步：从 main 分支创立两个分支，B1 和 B2;

第二步：B1 分支会创建两个新文件，F1 和 F2 。然后推送到 dev 分支；

第三步：B2 开始工作，修改了一个旧文件 F9 ，然后推送到 dev 分支，接着又把 B2 推送到 staging 和 main 分支，使命结束。我的流程中，并没有 dev->staging->main 的推送，而是每一次都从 feature 分支分别推送三次；

第四步：回到 B1 分支，Looker UI 强制 Pull & Merge ，因为检测到 main 有变动。其实完全没必要，因为 B1 和 B2 处理的文件完全不同。而且更重要的一点，这个会造成下一步的合并冲突；

第五步：还在 B1 分支，对 F1 做了一定修改之后，再次推送到 dev 分支，触发合并冲突。

我对版本管理不熟悉，对 git 的原理也不懂，请问为何会造成第五步的合并冲突？我试验了一下，如果第四步没有 Pull & Merge ，就没事，可惜这一步被 Looker 强制，没法跳过去。

Supplement 1 · Jul 23, 2022

不好意思，没写清楚，我重写一下。

第一步：从 main 分支创立两个 feature 分支，B1 和 B2;

第二步：B1 分支会创建两个新文件，F1 和 F2 。然后 B1 push 到 origin/B1 ，建立 PR-merge 到 dev ，成功；

第三步：B2 开始工作，修改了一个旧文件 F9 ，然后照样 PR-merge 到 dev 分支，接着又把 B2 PR-merge 到 staging 和 main 分支；

第四步：回到 B1 分支，Looker UI 强制 Pull & Merge ，因为检测到 main 有变动。其实完全没必要，因为 B1 和 B2 处理的文件完全不同。而且更重要的一点，这个会造成下一步的合并冲突；

第五步：还在 B1 分支，对 F1 做了一定修改之后，再次 PR-merge 到 dev 分支，触发合并冲突。

分支

dev

main

looker

7 replies • 2022-07-25 06:36:59 +08:00

aureole999

Jul 23, 2022 via iPhone

看不懂推送是什么意思。push 吗？
你把 B1 直接 push 到 dev ，那你 B2 怎么 push 的？强制 push ？
一般流程 B1 push 到 origin/B1 ，建 Pull Request 请求 merge 到 dev 。本地的话就是切换到 dev 分支，pull 一下，然后 merge B1 ，再 push 到 origin/dev 。B2 一样。

levelworm

Jul 23, 2022

@aureole999 1
不好意思我没说清楚，早知道用英文说了。所谓推送就是 B1->origin/B1 然后 PR-merge 进 dev 。

对，就是你说的这个流程，但是没有后半句本地那段，因为 Looker 就是本地。流程就是：Looker 里 create new branch B1 from main ，然后 B1 Commit & Push ，然后转到 GitHub 里，创建 B1->dev 的 PR ，最后 PR-merge ，大致就是这样，等等。

levelworm

Jul 23, 2022

现在的问题就是，不懂为什么第五步会有那个 merge conflict 。

我重写一下：

第一步：从 main 分支创立两个 feature 分支，B1 和 B2;

第二步：B1 分支会创建两个新文件，F1 和 F2 。然后 B1 push 到 origin/B1 ，建立 PR-merge 到 dev ，成功；

第三步：B2 开始工作，修改了一个旧文件 F9 ，然后照样 PR-merge 到 dev 分支，接着又把 B2 PR-merge 到 staging 和 main 分支；

第四步：回到 B1 分支，Looker UI 强制 Pull & Merge ，因为检测到 main 有变动。其实完全没必要，因为 B1 和 B2 处理的文件完全不同。而且更重要的一点，这个会造成下一步的合并冲突；

第五步：还在 B1 分支，对 F1 做了一定修改之后，再次 PR-merge 到 dev 分支，触发合并冲突。

aureole999

Jul 23, 2022 via iPhone

正常来讲 b1 建立了之后它就不会 tracking main 分支了，push 之后它 track 的就是 origin/b1 。我没用过 looker ，但一般来说 main 变没变跟 b1 就没关系了。b1 push 完你可以执行 git branch -vv 看看它 track 的是哪个 branch

levelworm

Jul 24, 2022 via Android

@aureole999 4
多谢，我其实更想知道 conflict 的原理，就是说，我能根据原理，判断出来这次 merge 一定有冲突，就行了。可是手册上似乎并没有写的很深入，也许我没找对地方。

aureole999

Jul 24, 2022 via iPhone

还是看改了什么代码，改不同文件不会造成冲突。假如要把 b1merge 到 dev ，我猜大概是找到公共祖先 commit ，把 b1 里所有不在 dev 里的 commit 找出来，按顺序一个一个 merge 到 dev 里。我猜你冲突的原因是 b2 merge 到 dev 和 main 因为是直接从 b2 merge 的，虽然同样的修改内容，但 commit 的 hash 并不一样。你看看 dev 和 main 同样的那个 b2 的 commit 的 hash 。

然后 b1 pull 了一下，这样 b1 就有了 main 的那个 b2 的 commit 。再 merge 到 dev ，dev 发现 main 里的那个 b2 的 commit 它没有，就想放进来，因为这里比较的是 hash 而不是真正的文件修改内容。想放进来的话就会发现和 dev 分支自己的 b2 commit 冲突了，因为同样修改了 F9 。

levelworm

Jul 25, 2022 via Android

@aureole999 我觉得你说的有道理，应该就是这个原因，就是同一个修改用了两个 hash 。感觉真是棘手，就差这个场景不能解决了。