代码之家 › 专栏 › 技术社区 › kraymer

Changelog的自定义git合并联合策略

changelog git

kraymer · 技术社区 · 6 年前

我们有一个 ONGOING.md
它看起来像:

### Added
- item 1

### Changed
- item 2

在拉/推代码时,行总是被覆盖,所以我添加了一个 .gitattributes repo根目录下的文件:

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

我以为那句话 “退回到修补基础和3路合并…” 意味着git解决了一个冲突,所以合并驱动程序应该发挥作用,不是吗?

所以引用@VonC:

但如果三方合并完成时没有冲突。。。没有调用合并驱动程序。

因此,我想我的问题可以重新表述为:如何配置git以实现3路合并当两个开发人员编辑同一节(如 ### Added

如果我们重新考虑我在Edit1中的例子,我不明白git最终是如何选择另一个开发行的,而不是我的或两者。

2 回复 | 直到 6 年前

VonC 6 年前

Merge drivers 在发生合并冲突时调用。

如果覆盖仍在发生,请检查开发人员是否在某个时间点没有这样做 push --force ,用自己的历史覆盖远程历史。

确保他们有:

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

这将迫使他们在当地解决 ONGOING.md

我认为“退回到修补基础和3路合并…”这句话意味着git解决了一个冲突,所以合并驱动程序应该发挥作用,不是吗?

如果公共祖先显示公共行正在被修改/合并,那么是的,将发生冲突,并调用合并驱动程序。
3-way merge 完成而没有冲突。。。没有调用合并驱动程序。

kraymer 4 年前

我注意到随着时间的推移,我的问题得到了一些关注,因此人们可能会对我如何处理这个问题感兴趣。

Gitlab wiki也是git存储库,因此此设置保留了对正在进行的更改日志进行版本控制的优点,同时避免了手动解决文本冲突的陷阱(只有当两个用户同时编辑wiki时才会发生冲突,而在使用上一个设置进行每次编辑后,冲突或多或少会出现)。