История редко бывает прямой линией
В вашем обновленном графическом изображении у вас есть новые коммиты к верху и более старые коммиты к низу. Все было превращено в красивую аккуратную прямую. Но это искаженное представление о реальности, точно так же, как искажено каждое представление. (Мы можем представить Эйнштейна и относительность, если это необходимо, чтобы доказать это, но давайте просто примем это как данность, что нам нравится смотреть на вещи с того места, где мы сидим / стоим сейчас, в отличие от того, где вещи были, когда они были, какими бы они ни были и у нас не было сегодняшней перспективы. Завтра или в следующем году у нас будет еще одна перспектива!)
Давайте перерисовать эту историю другим способом, чтобы прояснить ситуацию. Мы поместим более старую работу в слева , а более новую работу в справа и нарисуем ее параллельно , например:
...--o--o---o
\
X--X--X <-- master
/
...--o---X--X <-- feature/buggy
^
|
bug introduced
где X представляет коммит с ошибкой. Обратите внимание, что первый ошибочный коммит в нижнем ряду пришел после одного из хороших коммитов, показанных в верхнем ряду, затем второй ошибочный коммит пришел одновременно (или даже немного раньше) с последним хорошим коммитом в верхнем ряду , Ошибка, очевидно, была впервые введена в отмеченную мною точку.
Теперь, если мы рисуем эту линеаризацию по вертикали с новыми коммитами вверху, мы получаем:
.
.
.
X (still has bug introduced by merge)
X (bug first introduced by merge)
o (commit from the top row, not broken)
X (bug in feature/buggy - commit from the bottom row)
X (bug in feature/buggy)
o (commit from the top row, not broken)
.
.
.
В линеаризованной вид, глючные коммиты разделены хорошими коммитами. В «правильном» (или, по крайней мере, менее искаженном) представлении, которое просматривает историю по одной «ноге» за раз, ошибочные коммиты все в ряд.
Фактическое представление, которое вы показываете в обновленном graphi c, имеет коммит, чье сообщение в журнале говорит Merge remote-tracking branch 'AWS/... (это обрезается), но не является коммитом merge (коммит с двумя или более родителями) , Это тип слияния, осуществляемый git merge --squash, или - на некоторых веб-интерфейсах - нажатием кнопки с надписью что-то вроде «squa sh and merge». Эти коммиты выполняются с использованием Git механизма слияния , но не записывают правильную историю. 1 Так что в этом случае, единственный способ узнать это от har sh опыт: я видел именно такую проблему раньше. Графики, которые я здесь нарисовал, показывают, как все выглядело бы, если бы слияние было обычным слиянием, а не слиянием sh.
Ничто из этого не является критическим, но кто-то в вашей организации вероятно, потребуется некоторое время и узнать, как Git работает на мелком уровне, чтобы упростить поиск и исправление ошибок в будущем.
1 Это часто преднамеренно Идея состоит в том, чтобы рассказать историю ie, чтобы облегчить дальнейшее расследование, даже на самом деле оно усложняет будущее расследование. Насколько хорошо работает эта функция «squa sh», зависит от навыков и знаний тех, кто ее использует. Любой, кто использует его вслепую, использует его неправильно, в том смысле, что любой, кто использует электроинструменты, не научившись использовать их безопасно, использует их неправильно, даже если они случайно используют их правильно. ?