Как избежать конфликтов в git?

Question

[ince]

Есть основной репозиторий с одном файлом.
Этот репозиторий форкают несколько разработчиков и начинают вносить изменения в свои копии.
После присылают свои пуллреквесты в основной репозиторий.
Но с момента, когда один присылает пулл реквест, кто-то другой уже успел внести изменения в этот файл в основном репозитории.
И из-за этого возникает конфликт.
Не хочется каждый раз решать его вручную.
Посоветуйте, как решить проблему?
(файл разбить на несколько нельзя)

Comments

[Lynn «Кофеман»]

> (файл разбить на несколько нельзя)
Страдать

[Дмитрий Гординский]

Что мешает разбить содержимое файла?
Что за данные в нём хранятся, что их нельзя фрагментировать?

Answer 1

[Владимир]

Не ты должен решать, разработчик перед тем как сделать пул реквест должен сделать в своей ветке

git fetch
git rebase origin/master

и после этого решить все конфликты а только потом
git push
Единственный выход для минимизации конфликтов - бить файл на кусочки.

Если человек работает в форке, то ему нужно сначала стянуть изменения себе в мастер с основного репозитория

Comments

[ince]

git fetch
git rebase origin/master
... изменения файла...
git push

Так?

[Владимир]

rebase нужно делать сразу перед созданием пул реквеста, а не перед тем как редактировать файл.

По факту не обязательно ребейсить изменения из мастера в фиче фетку, можно и мержем их затягивать, главное это делать сразу перед тем как создавать пул реквест. Ну и пре ребейсе история получается красивее

Answer 2

[Robur]

Если вам прислали пулреквест с конфликтом - отправляете его обратно, разработчик должен переделать его.
Если конфликты сыпятся постоянно - это повод пересмотреть работу, либо пулл реквесты сильно большие, либо код перемешан в лапшу так что каждое изменение затрагивает много участков, либо задачи такие что разработчики делают изменения в одном и том же месте.
Это надо выяснить и исправить.

Comments

[ince]

В проекте всего один файл и все вносят изменения в него.
Вот и вопрос как организовать работу корректно.

[Евгений Самсонов]

ince, небольшие пул реквесты, авторы сами решают конфликты, максимально быстрый мерж в основную ветку

[Robur]

ince, это не имеет значения - работа с разными частями одного файла и с разными файлами одного проекта по сути строится одинаково и проблемы-решения тоже во многом одинаковые.

Answer 3

[Владимир Коротенко]

Покажите файл. Хотя, в общем то, стоит как то организовывать работу. Например указать разработчикам что бы работали над одной атомарной единицей за раз.

Например вносили изменения только в 1 функцию.