git - 从 fork 推送时 merge 冲突的正确方法？

Question

我最近发现，将机会从 fork 推送到主存储库的正确流程是这样的:

1. 在分支上创建问题分支

2. 创建 Pull 请求以将此分支 merge 到上游的主分支

3. 将更改从上游 pull 入 fork master

4. 将更改从 fork master 推送到远程 fork master

一切正常，但我不知道遇到 merge 冲突时该怎么办。

也就是说，我为 3 个问题创建了 3 个分支并完成了它们。我将分支推送到远程 fork 存储库，并准备好创建 PR。我为 BranchA 创建 PR，但它说“它无法自动 merge ，因为我必须解决冲突”。

解决包括我首先将此分支 merge 到 fork master，解决冲突，然后将 merge 的更改推送到上游主存储库。

我不是刚刚违反了上面提到的四步规则吗？

有没有办法不 merge fork master 上的任何内容，而是解决分支内部的冲突并通过 PR 将固定分支推送到上游？

Answer 1

I've recently discovered on SO that the proper flow to push chances from a fork to the master repo is this:

git 没有“正确”的流程。 Git 与工作流程无关，并且没有规定的工作顺序。您必须了解它的作用并使其适应您的需求。

我认为你描述的四点完全错误。

更详细地说，工作程序是(分支像这样):

• 在分支存储库上创建一个分支，将其 pull 入本地工作存储库
• 在分支本地工作
• 在分支上进行一些提交
• 将 master-master pull 到本地 master(这是一个简单的快进，您从未接触过 master)
• 本地将master merge 到branch(或者，如果您自己处理branch，更好的是，进行 rebase )。这是手动解决冲突的地方。
• 将新的 master 和 branch 推送到 fork。
• 创建从 fork-repos 到 master-repos 的 branch PR，根据定义，现在它也是无冲突的(直到其他人修改 master-master再次)。