Git Merge просто против сквоша. Какова цель? Как отследить один коммит на функцию?

Question

Одна вещь, которая мне не нравится в Git - это количество коммитов. Не поймите меня неправильно, это очень удобный способ (безопасно) хранить вашу работу, но в долгосрочной перспективе слишком много деталей для поиска.

Позвольте мне описать следующий сценарий при разработке с использованием ветвей функций, разветвленных от разработки.

• Feature1 является ответвлением от Develop и имеет 5 коммитов
• Feature2 является ответвлением от Develop и имеет 3 коммитов
• Feature3 является ответвлением от Feature1 и имеет 5+2 коммитов.

Причина состоит в том, что есть три ветви, потому что есть команда, работающая над хранилищем. Feature3 предполагает, что Feature1 завершена, ожидая объединения с разработкой. Для этого есть и другие варианты использования, но это самый простой пример.

Моя цель - сделать три коммита в разработке, когда все функции будут выполнены.

Использование git merge / pull

Приведенный выше сценарий работает хорошо. Потому что по сути обе команды перемещают коммиты в ветку разработки. Когда Feature1 объединен, разработайте ссылки, это пять коммитов. Когда Feature3 будет объединен, только два последних коммита будут объединены в разработку.

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

Использование git merge с squash

Когда Feature1 объединен, Develop получает новый коммит, который является объединением всех Feature1. Это очень хорошо, так как функция теперь отслеживается только с одним коммитом. Когда Feature1 удален, все промежуточные коммиты больше не видны, что облегчает отслеживание. Это также согласуется с такими понятиями, как один запрос на выборку и одна проблема с github.

Когда Feature3 собирается объединиться, возникают конфликты, и проблема начинается. Чтобы решить эту проблему, вам нужно объединить разработку обратно с feature3. с конфликтами. В результате получается новый коммит с нулевым изменением файлов. И теперь мы объединяем сквош Feature3 для разработки.

Моя цель достигнута, но с большой потерей микроуправления.

Вопросы / замечания

Насколько я понимаю, это мерзкая реальность. Один совет, который я прочитал, состоит в том, чтобы создать дочернюю ветвь функций, которая содержит сжатый коммит слияния. Используйте одноуровневую ветвь для запроса извлечения, поэтому принудительное использование одного коммита на функцию. Это не решает конфликты, возникающие при попытке объединить другие ветви, особенно те, которые наследуются от других функциональных ветвей.

• Можно ли сделать внутренний сквош в той же ветке? Я так не думаю, но не больно спрашивать.
• Я что-то упустил?
• Это компромисс слияния сквоша? Разрешение конфликтов, которые могут иметь нулевые изменения кода?
• Стоит ли искать концепцию "один коммит на функцию"?
  • Если нет, то какова цель игры в сквош? Кто этим пользуется?

Я прочитал альтернативу с rebase и имитировал сквош со сбросом после слияния, но, насколько я понимаю, никто не решает накладные расходы, упомянутые при слиянии feature3.

Answer 1

Да, цель git с таким количеством коммитов - отслеживать все изменения. Если некоторые коммиты несущественны или можно записать все изменения в одном коммите, чтобы вы просмотрели историю, вы можете уничтожить эти коммиты.

По вашим вопросам:

1. Да, вы можете сделать внутренний сквош. Предположим, ваша история коммитов git представлена ​​на графике ниже:

                K---L---M        Feature2
              /
A---B---…---C---…                develop
     \         
      D---E---F---G---H          Feature1
                        \
                          I---J  Feature3

Вы можете использовать эти шаги, чтобы раздавить каждую ветку:

git checkout Feature1
git rebase -i HEAD~5

вход i

pick D
squash E
squash F
squash G
squash H

нажмите кнопку Esc, а затем введите :wq

git checkout Feature3
git rebase -i HEAD~7

pick D
squash E
squash F
squash G
squash H
squash I
squash J

git rebase Feature1
git checkout Feature2
git rebase -i HEAD~3

pick K
squash L
squash M

2. Ваш процесс в порядке.
3. Чтобы сдавить коммиты, первый (самый старый) должен использовать выбор, а другие могут использовать сквош, чтобы он показывал ветку только с одним коммитом. Если есть конфликт, вы можете изменить и сохранить файлы конфликта, а затем использовать git add . а также git rebase --continue,
4. Это не обязательно, и это зависит от вашего любимого. Основная цель игры в сквош - сделать историю более аккуратной и понятной.

Answer 2

Я действительно думаю, что перебазирование это ваше решение здесь.

Если я понимаю, следующая структура вашего git:

develop \ A - B - C [feature1] \ D - E [feature3]

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

develop — feature1Merge \ A - B - C [feature1] \ D - E [feature3]

Таким образом, коммит feature1Merge в разработке отличается от тех, что были в истории feature3.

В этом случае, если вы пытались rebase Feature3 вернуться к разработке, фиксирует AB а также C будет идти с этим, что в теории не должно приводить к каким-либо проблемам, так как изменения уже в разработке, поэтому git должен просто перенести эти коммиты вперед. Очевидно, этого не происходит, хотя.

В этой ситуации я бы предложил rebase onto,

Перебазировать на

--onto Опция позволяет перебазировать конкретные коммиты, а не целую ветку.

Так что, чтобы остановить git, пытаясь использовать коммиты AB а также C при ребазинге используем --onto, который принимает 3 аргумента:

• Новая база для филиала

• Текущая база филиала

• Название ветки для ребазирования

В вашем случае это будет:

git rebase --onto develop C feature3

Это проверяет разработку и затем применяет все коммиты на feature3, так как C:

develop — feature1Merge \ D - E [feature3]

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