您可以强制手动合并 git 存储库中的文本文件吗？

Question

动机

在我们的软件开发中，经常会出现多个开发人员同时对CHANGELOG.md进行修改的情况。假设我们的主分支看起来像这样。

## Unreleased

change X
change Y

如果在一个分支上，我们创建一个新版本：

## Unreleased

## [1.0.0] - 2023-01-27

change X
change Y

而在另一个 change Z 上介绍：

## Unreleased

change X
change Y
change Z

如果更改分支在发布分支之后合并，自动合并很可能会像这样愉快地合并 CHANGELOG.md：

## Unreleased

## [1.0.0] - 2023-01-27

change X
change Y
change Z

Change Z 被置于发行版之下，即使它不是发行版的一部分！

正确的 CHANGELOG.md 看起来像这样：

## Unreleased

change Z

## [1.0.0] - 2023-01-27

change X
change Y

问题

我们没有对变更日志进行自动化测试，所以我想知道是否可以强制开发人员在进行并行更改（三向合并）时手动合并变更日志。

同时，我希望我们的工具 (VSCode) 将 CHANGELOG.md 文件视为一个文本文件。

理想情况下，团队中的任何人都不必在克隆后执行任何手动步骤。

我已经尝试过的

我添加了一个 .gitattributes 文件并使用了 diff 和 merge 属性。

CHANGELOG.md -merge diff

虽然使用 -merge 取消设置 merge 属性确实会强制合并，但尽管使用 diff 设置了 diff 属性，文件仍被视为二进制文件。我尝试了更多组合，但到目前为止我还没有找到两者的组合：

1. 允许我以文本形式查看差异
2. 强制手动解决三向合并（强制冲突）

Answer 1

关于修复合并

1. 正常合并：merge <branch-name>
2. 如果合并因冲突而停止，请以您选择的任何方式解决它们。
3. 如果一个文件（repo 中的任何文件，而不仅仅是在<branch-name> 中有新更改的文件）没有正确合并，编辑文件，add 他们，然后运行commit --amend 来修改该更改进入合并提交.

   提醒：在您的文件处于正确状态之前不要推送。

   关于修复团队的合并策略

   我们没有对变更日志进行自动化测试，所以我想知道是否可以强制开发人员在进行并行更改（三向合并）时手动合并变更日志。

   根据您的托管平台，您可以采用以下规则：

   • 不允许开发人员推送非功能分支（例如master）。这有时在回购设置中被称为“受保护的分支”。
   • 因此，开发人员必须打开一个 PR 才能将更改更改为master。

   如果您的团队最终仍然提交损坏的 CHANGELOG.md，那么可能是时候为该文件实际开发 CI 测试，以便它至少针对每个合并请求运行。