Как избежать повторяющихся коммитов в Git при применении исправлений с использованием модели разработки Git-потока ветки разработки? - PullRequest
Новая
       73

Как избежать повторяющихся коммитов в Git при применении исправлений с использованием модели разработки Git-потока ветки разработки?

3 голосов
/ 05 апреля 2019

Мы используем модель развития филиала develop в одном из наших проектов. 

o - - - A - o - o - o - o  master
| \   /
 \  o  hotfix1
  \   \
    o - B - o - o - o develop

На приведенной выше диаграмме требуется hotfix1, и мы применяем (объединяем) его в обоих master и ветка develop.Это приводит к 2 различным идентификаторам фиксации A и X.

Позже нам понадобится новое исправление, которое снова применяется в master, что приводит к фиксации C: 

o - - - A  ...  A - - - C  master
| \   /           \   / 
 \  M  hotfix1       N  hotfix2
  \   \               \
    o - X - o - o - o - ?(A, N)? develop

Но слияниеhotfix2 в ветку develop мы получаем следующий список коммитов в запросе на слияние (терминология GitLab): 

N
A

Это имеет несколько недостатков:

  • рецензент кода увидит гораздо больше изменений, чем в коммите N, даже если все эти изменения уже находятся в develop (через коммит X).Это усложняет обзор.
  • после слияния, в develop мы видим как X, так и вновь выведенный A (посредством слияния N).Таким образом, мы имеем одинаковые изменения и одинаковые сообщения git commit (git log) в двух разных коммитах.

Как мы можем избежать такого дублирования коммитов в master и develop?Мы хотели бы продолжить использовать модель ветки develop.

Ответы [ 2 ]

2 голосов
/ 05 апреля 2019

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

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

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

2 голосов
/ 05 апреля 2019

Вместо слияния исправления (ветки) в разработке, вы можете выбрать (git cherry-pick <commitHash>) коммит (ы), содержащий исправления, это создаст следующее: 

o - - - A  ...  A - - - C  master
| \   /           \   / 
 \  M  hotfix1       N  hotfix2
  \   \
   o - X - o - o - o - N' develop

N 'будет иметь то же содержимое, что и N, но не с теми же родителями, поэтому не тот же хеш, но также отсутствие тех же родителей означает, что в вашем запросе на слияние не будет присутствовать А.

...