Проблема рабочего процесса Git - раздавленные коммиты и конфликты

Question

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

1. git pull - Это должно быть сделано в основной ветви.
2. git checkout -b TASK-ID - Создать новую ветвь для задачи. TASK-ID будет выглядеть примерно так: TASK-101
3. Работайте над задачей и фиксируйте изменения по мере необходимости.
4. По завершении задачи,git checkout master
5. git pull - Получить любые изменения, которые были сделаны с момента последнего извлечения.
6. Устранить любые конфликты и убедиться, что текущая версия в мастер-компиляциях.
7. git merge --squash TASK-ID - При слиянии все коммиты в ветви обрабатываются как один коммит.
8. git commit - Добавить любую дополнительную информацию, в частности, TASK-ID , в сообщение о коммите.,Следует отметить, что все сообщения коммита из ветви включены, поэтому они не были потеряны при слиянии.
9. git push - Перенесите изменения обратно на сервер.

* 1035Немного предыстории: в настоящее время мы не много работаем над этим, мы не часто видим конфликты.Причина сдавленного коммита в том, что у нас есть один коммит для каждой задачи.Таким образом, если наш сервер Bamboo обнаружит проблему со сборкой, мы можем легко привязать ее к задаче и попросить разработчика исправить ее.Кроме того, он сохраняет чистоту основной истории, потому что я, по крайней мере, склонен делать много коммитов.Да, я знаю, что это может измениться, если мы начнем работать с более крупными командами, но это в будущем.

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

Итак, подведем итог: у меня есть следующие требования:

1. Очистить историюв мастере
2. Может видеть изменения в ветке в сообщении для одного коммита
3. Сообщение коммита для сдавленного коммита необходимо отредактировать, чтобы в нем был идентификатор задачи, прежде чем коммититьменять.(Поправка тоже может сработать).

Answer 1

Вы должны понимать, что merge --squash имеет некоторые недостатки:

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

Правильный способ сделать то, что вы хотите, по-видимому, подробно описан в этого ответа . Я говорю, очевидно, потому что я еще не проверял это - сделаю очень скоро, поскольку я хочу этот ответ для себя .
Чтобы получить сообщения коммита из вашей ветки TASK-101, попробуйте то, что предложено здесь

Изменить: На ваш оригинальный вопрос ответ в .git/SQUASH_MSG

Answer 2

Может быть, я неправильно понял, но обычно я делаю так, чтобы мой мастер всегда оставался равным или находился позади мастера от источника. Таким образом, когда я делаю git pull, он никогда не делает никаких слияний (поскольку история мастера никогда не бывает переписан в моей команде). После того, как я сделаю git pull, я иду в ветку TASK-101 и объединяю результаты мастера в эту ветку. Таким образом, задача 101 будет иметь мои коммиты, коммиты, которые находятся в master, и, возможно, коммит слияния. Я могу делать это каждый раз, когда чувствую необходимость обновить свое рабочее репо.

Когда я готов к коммиту, я делаю это в последний раз, а затем иду к мастеру и сквошу, объединяю коммит из задачи-101, а потом делаю dcommit, чтобы избежать вероятности конфликтов из-за временного окна. между последним толчком и толчком очень мало (в моей команде такого никогда не было. Если это произойдет. Если это когда-нибудь произойдет, мне, вероятно, придется уведомить команду и переписать историю).