如何使用 git flow 解决与 composer.lock 的合并冲突？

Question

我正在开发一个 Laravel 项目并使用 git-flow 来管理我的更改。我的 develop 分支是我最近完成的名为 feature/registration-captcha 的功能分支之前的两次提交。我想将此功能分支合并到开发分支中。

我最近提交的并入开发分支的提交只是运行composer update 来更新其中有错误的包。所以，composer.lock 文件当然已经被修改了。

feature/registration-captcha 功能分支包括向注册页面添加验证码包和验证码 UI。所以，这也修改了composer.lock文件。

当我坐在功能分支上时，我尝试从源树中合并提交，方法是选择 Repository > Git Flow > Finish Feature，然后在 Finish Feature 弹出：

然后我会收到以下消息：

这会产生一个composer.lock 文件，其中包含需要解决的合并冲突。我认为解决此问题的最佳方法是删除composer.lock 并通过运行composer update 或composer update --lock 创建一个全新的更新副本，添加未暂存的composer.lock 文件并提交更改。完成此操作后，我的提交如下所示：

当从命令行运行 git status 时，我会看到以下内容：

c:\my-project (HEAD detached at 2a9ff12)
λ git status
rebase in progress; onto 3070450
You are currently rebasing branch 'feature/registration-captcha' on '3070450'.
  (all conflicts fixed: run "git rebase --continue")

nothing to commit, working directory clean

所以我认为正确的做法是运行git rebase --continue，之后我收到以下消息：

c:\my-project (HEAD detached at 2a9ff12)
λ git rebase --continue
Applying: add non captcha to registration page
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

如果我再次运行 git status，我会看到与上次运行 git status 时相同的消息。

所以我现在想知道：

• 我应该在这里做什么来完成变基/合并？
• 我做错了吗？
• 我是否应该处理因更新包不同而可能引起的冲突？

任何帮助将不胜感激，谢谢！

Answer 1

我做错了吗？

由于 git 在工作流程方面非常灵活，因此总是有不止一种方法可以做到这一点。 ;)

在这种特定情况下出现的问题 - 如果我正确理解您的操作顺序 - 是您在合并完成之前启动了 rebase，因为您想使用它来解决合并冲突。这就是你最终处于分离头部状态的方式。

我是否应该处理因更新包不同而产生的冲突？

如果您遇到合并冲突，则您处于合并开始但尚未完成的状态。它可以中止（但没有合并）或完成（解决冲突并提交更改）。

对于composer.lock，我会首先尝试手动解决合并冲突，因为冲突应该非常明显：一些包更新，另一个添加 - 冲突可能是双方更改了几行。 composer.lock 是 JSON 格式的文件，因为您可以从两个可用的分支中获得正确工作的版本，这应该很容易修复。也许SourceTree在这里提供了一个冲突解决工具（我不使用它），但这也可以在文本编辑器（git marks the conflicting blocks）或Meld和VimDiff等工具中使用（可以由@调用987654324@) 并向您展示 3 或 4 个文本窗口：来自两个分支的版本、具有当前状态的冲突解决窗口（在这里您进行更改）和（可选）两个分支的基本版本和一个侧面-横向比较。保存它，测试它（composer install 应该告诉你composer.lock 文件是否有问题，或者composer validate）。然后添加并提交——git 仍然知道提交属于合并。

在这种特定情况下解决冲突的另一种方法（文件不是手动编辑，而是由程序编辑，您知道在两个分支上做了什么）是：当您在合并时，出现冲突时，检查composer.lock 来自开发（仅此文件），并运行添加新包的 composer 命令，就像您在分支中所做的那样，添加并提交。结果就像您按顺序运行更新和添加包一样。

我应该在这里做什么来完成变基/合并？

如果您的工作目录或分离头中没有其他更改，并且开发也仍处于描述中的状态，我将重新开始合并：

• git rebase --abort 如果变基仍在进行中
• git merge --abort 如果合并仍在进行中
• 结帐开发
• 再次合并功能分支
• 以所述方式之一解决冲突
• 提交合并（包括解决冲突的更改）、推送等。