Question

我们有一个ONGOING.md文件，每个开发人员在推送代码时都会在其中添加项目。
看起来像：

### Added
- item 1

### Changed
- item 2

在拉/推代码时，所有的行都被覆盖，所以我在回购根目录添加了一个.gitattributes文件：

ONGOING.md -text merge=union

我希望此后所有书面行都得到保留，但事实并非如此，仍然会发生覆盖。

处理此问题的正确方法是什么？

编辑：

好的，这只是发生了，所以我复制/粘贴了终端的内容：

$ more fab/hotfix/ONGOING.md 
### Added

$ nano fab/hotfix/ONGOING.md; git commit fab/hotfix/ONGOING.md -m "update ongoing"

$ more fab/hotfix/ONGOING.md 
### Added
- add slug column to BO fack topic  admin  page

$ git pull
remote: Enumerating objects: 14, done.
remote: Counting objects: 100% (14/14), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 14 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (14/14), done.
From gitlab.com:kraymer/website
   a740fe8a0..12d531e8d  hotfix              -> origin/hotfix
First, rewinding head to replay your work on top of it...
Applying: add slug column to BO fack topic  admin  page
Using index info to reconstruct a base tree...
M   fab/hotfix/ONGOING.md
Falling back to patching base and 3-way merge...

$ more fab/hotfix/ONGOING.md 
### Added
- shared task for old notifications to be deleted

我认为句子“回到修补基础和三向合并...” 意味着git解决了冲突，因此合并驱动程序应该发挥作用，不是吗？

编辑2：

因此引用@VonC：

但是，如果三路合并完成而没有冲突...则不会调用合并驱动程序。

因此，我想我的问题可以这样表述：如何配置git，以便在ONGOING.md上进行三向合并时，当2个开发人员编辑同一节（例如，### Added中的{我之前的示例），这样合并驱动程序就起作用了吗？

如果我们重新考虑Edit1中的示例，我不知道git最终会如何选择其他开发行而不是我的行或两者都行。

Answer 1

如果合并冲突，则会调用

Merge drivers。

如果仍在进行覆盖，请检查开发人员在某个时候push --force上是否没有执行操作，以自己的方式覆盖远程历史记录。
或者，如果他们以某种方式忽略了所进行的更改（通过从IDE中保存其本地副本，覆盖了刚刚进行的更改）

确保它们具有：

git config --global pull.rebase=true
git config --global rebase.autostash=true

这将迫使他们进行ONGOING.md的本地解析，并在从远程拉出的提交之上重播自己的提交。

我认为“回退到修补程序基础和三向合并...”一词意味着git解决了冲突，因此合并驱动程序应该起作用，不是吗？

否：这只是意味着它需要公共祖先才能进行合并。
如果该共同祖先显示了共同的行被修改/合并，那么是的，将会发生冲突，并且将调用合并驱动程序。
但是，如果 3-way merge 完成而没有冲突，则不会调用合并驱动程序。

Answer 2

我注意到我的问题随着时间的流逝越来越受到关注，因此人们对我的处理方式可能会很感兴趣。
关注的是要有一种方法来记录不同分支机构正在进行的更改。
为避免编辑时发生冲突，我们没有直接在存储库中而是在项目Wiki存储库中托管文本文件：因此，每个分支都有一个Wiki页面，并且我们通过gitlab Web界面进行编辑，以在并行编辑时处理冲突很好。

Gitlab Wiki也是git信息库，因此此设置保留了对正在进行的变更日志进行版本控制的优势，同时避免了手动解决文本冲突的陷阱（仅当两个用户同时编辑Wiki时出现冲突，而在以后用户或多或少地出现此冲突）每次修改都使用以前的设置。

Answer 3

您基本上在源代码管理中有一个变更日志-变更日志可以描述对源代码管理的更改。你在跳舞可以将变更日志视为从构建生成的工件。

git rm ONGOING.md

摆脱文件并从提交消息中生成它。您遇到了一个非常小的问题-更有可能是有人忘记添加。 commit.template可以帮助您的团队为有意义的消息提供一致的变更日志。

或者结帐commitizen，以获得更重的方法

签出github-changelog-generator

变更日志的自定义git合并联合策略

3 个答案: