Пользовательская стратегия объединения git merge для журнала изменений

Question

У нас есть файл ONGOING.md, в который каждый разработчик добавляет элемент при нажатии на код.
Похоже:

### Added
- item 1

### Changed
- item 2

Все время происходило перезапись строк при извлечении / отправке кода, поэтому я добавил файл .gitattributes в корень репо:

ONGOING.md -text merge=union

Я ожидал, что каждая записанная строка будет сохранена после этого, но это не так, перезаписи все еще происходят.

Как правильно бороться с этим?

Edit:

ОК, это просто произошло, поэтому я копирую / вставляю содержимое моего терминала:

$ 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 разрешил конфликт, поэтому драйвер слияния должен войти в игру, не так ли?

Edit2:

Итак, цитируя @VonC:

Но если трехстороннее слияние завершается без конфликтов ... драйвер слияния не вызывается.

Так что я думаю, что моя проблема может быть перефразирована следующим образом: как я могу настроить git так, чтобы трехстороннее слияние на ONGOING.md заканчивалось конфликтом, когда 2 разработчика редактируют один и тот же раздел (как ### Added в моем предыдущем примере) , такой, что в игру вступает драйвер слияния?

Если мы пересмотрим мой пример в Edit1, я не пойму, как git заканчивает тем, что выбирает другую линию разработки, а не мою или оба.

Answer 1

У вас, по сути, есть журнал изменений в системе контроля версий, где журнал изменений может описывать изменения в системе контроля версий Ты танцуешь с собой. Думайте о журнале изменений как о сгенерированном артефакте из вашей сборки.

git rm ONGOING.md

Избавьтесь от файла и сгенерируйте его из сообщений коммита. Вы столкнулись с довольно незначительной проблемой - более вероятно, что кто-то забудет добавить к ней. commit.template может помочь вашей команде в создании значимых сообщений для согласованного журнала изменений.

Или оформить заказ совершить для более тяжелого подхода

Оформить github-changelog-generator

Answer 2

Драйверы слияния вызываются в случае конфликтов слияния.

Если перезапись все еще происходит, проверьте, не делают ли разработчики в какой-то момент push --force, переопределяя удаленную историю своей собственной.
Или, если они каким-то образом игнорируют извлеченные изменения (сохраняя свою локальную копию из IDE, переопределяя только что извлеченные)

Убедитесь, что у них есть:

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

Это заставит их делать локальное разрешение ONGOING.md, воспроизводя их собственные коммиты поверх тех, которые были извлечены с пульта.

---

Я подумал, что предложение «Откат к исправлению базы и трехстороннему слиянию ...» означало, что git разрешил конфликт, поэтому драйвер слияния должен войти в игру, нет?

Нет: это просто означает, что для слияния нужен общий предок.
Если этот общий предок показывает, что общие линии изменяются / объединяются, тогда да, возникает конфликт, и вызывается драйвер объединения.
Но если 3-стороннее слияние завершается без конфликтов ... драйвер слияния не вызывается.