这是一个创建于 847 天前的主题，其中的信息可能已经有所发展或是发生改变。
求问一个版本管理的问题：
三个分支: 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 强制，没法跳过去。
第 1 条附言 · 2022-07-23 09:30:34 +08:00
不好意思，没写清楚，我重写一下。
第一步：从 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 分支，触发合并冲突。
第一步：从 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 分支，触发合并冲突。
 |
1
aureole999 2022-07-23 09:13:41 +08:00 via iPhone  1
看不懂推送是什么意思。push 吗？
你把 B1 直接 push 到 dev ，那你 B2 怎么 push 的？强制 push ？ 一般流程 B1 push 到 origin/B1 ，建 Pull Request 请求 merge 到 dev 。本地的话就是切换到 dev 分支，pull 一下，然后 merge B1 ，再 push 到 origin/dev 。B2 一样。 |
 |
2
levelworm OP @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 ，大致就是这样，等等。 |
|
3
levelworm OP 现在的问题就是，不懂为什么第五步会有那个 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 分支，触发合并冲突。 |
|
4
aureole999 2022-07-23 10:26:38 +08:00 via iPhone 1
正常来讲 b1 建立了之后它就不会 tracking main 分支了，push 之后它 track 的就是 origin/b1 。我没用过 looker ，但一般来说 main 变没变跟 b1 就没关系了。b1 push 完你可以执行 git branch -vv 看看它 track 的是哪个 branch
|
|
5
levelworm OP @aureole999 4
多谢，我其实更想知道 conflict 的原理，就是说，我能根据原理，判断出来这次 merge 一定有冲突，就行了。可是手册上似乎并没有写的很深入，也许我没找对地方。 |
|
6
aureole999 2022-07-24 10:37:05 +08:00 via iPhone 1
还是看改了什么代码，改不同文件不会造成冲突。假如要把 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 。 |
|
7
levelworm OP @aureole999 我觉得你说的有道理，应该就是这个原因，就是同一个修改用了两个 hash 。感觉真是棘手，就差这个场景不能解决了。
|
Select Language