Автоматически переписывать полную историю Git, чтобы избавиться от простых коммитов слияния

Question

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

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

Кто-нибудь знает, как это сделать?

Answer 1

По моему мнению, вам следует избегать соблазна переписать историю просто для того, чтобы она "хорошо выглядела". Там действительно нет смысла. История, как она есть, является более точным представлением реальности, и все инструменты отчетности git разработаны так, чтобы быть полезными даже при большом количестве небольших слияний.

Если вы не заинтересованы в просмотре большого количества слияний, вы можете исключить их из многих задач по составлению отчетов, например,

git log --no-merges

То, что вы предлагаете (вечер переутомления, по-видимому, заставляющий всех разработчиков приходиться reset), похоже на создание работы ради работы.

Answer 2

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

Если вы вызовете его как rebase -i -p, с другой стороны, он сохранит слияния, чего вы и хотите, когда пользователь совершил реальное слияние, но в противном случае полностью упускает точку.

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

Я должен согласиться с Чарльзом, однако, что то, что история отражает реальность, гораздо ценнее, чем "красиво выглядеть". Дело в том, что один коммит был сделан без ведома другого, и в случае исходного кода это может сказать вам, почему что-то пошло не так.

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

Что плохого в том, чтобы всегда тянуть с --rebase (например, git pull -r)? Если вам нужна плоская топология, самый простой способ - не объединять, когда вы можете выполнить ребазинг.

Также: вы говорите, что хотите сгладить только, если "слияние чистое". Я просто размышляю здесь, но я не думаю, что записи в git конфликтуют после факта, отличного от примечания в сообщении о фиксации по умолчанию, которого может и не быть.