Git Merge Feature Branch БЕЗ любой истории коммитов

Question

говорят, что я создаю новую ветку функций и делаю кучу коммитов в ветке функций.Мой коллега также делает некоторые коммиты, так что основная ветка.Как я могу объединить свое изменение с главной веткой, но основная ветвь покажет один коммит?Я попытался объединить, все коммиты появляются, и это показывает, что я разветвляюсь.Я пробовал перебазирование, которое не показывает, что я разветвляюсь, но все еще показывает все мои коммиты.Заранее спасибо за помощь.

Answer 1

Как мне объединить мои изменения с главной веткой, но основная ветвь покажет один коммит?

Это несколько двусмысленно.

Обычное слияние добавляет один новый коммит, но этот новый коммит включает все коммиты из "другой" ветви в историю "этой" ветки - все они становятся "достижимыми" из этой ветки - так что по умолчанию вывод таких команд, как git log, показывает все эти коммиты, как вы заметили.

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

git log --first-parent

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

В частности, сохраняемая информация может быть особенно важной, если ветвь "other" была передана другим разработчикам, что является наиболее распространенным предположением, если вы когда-либо push редактировали ветку "other".

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

Вы можете попытаться «съесть свой торт и съесть его», но с помощью слияния --squash создайте упрощенную историю, сохраняя при этом исходную ветвь для мелкозернистой истории. Но в этом случае git потеряет связь между историями, и это может легко привести к гораздо большим проблемам, чем оно того стоит.

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

Answer 2

Используйте git merge --squash (что также заставляет вас использовать git commit впоследствии).

Описание

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

Есть несколько способов сделать это, но самый простой - использовать git merge --squash.Эта команда выполняет то, что я называю «частью глагола», для слияния - чтобы выполнить действие слияния, - вместо того, чтобы сделать коммит слияния , который является прилагательной или существительной частьютипичный git merge, он делает обычный коммит без слияния.

Точнее, он пропускает финальный коммит, заставляя вас делать это самостоятельно, используя git commit.Последний коммит, который вы должны сделать сами, это обычный коммит без слияния.Если мы рисуем коммиты так, как мне нравится, мы начинаем с этого:

...--o--o--o   <-- mainline
      \
       o--o--o   <-- yourbranch

Если вы делаете обычное ежедневное слияние с помощью git checkout mainline; git merge yourbranch, результат будет:

...--o--o--o---M   <-- mainline
      \       /
       o--o--o   <-- yourbranch

вот почему ваши три коммита теперь добавляются в ветку main-line: commit M, новое слияние, имеет двух родителей, один из которых является исходным main-line, а другой - вашим собственнымветка.(Ваши три коммита теперь находятся в обеих ветвях.)

Однако, если мы используем git merge --squash, мы получаем это вместо:

...--o--o--o---S   <-- mainline
      \
       o--o--o   <-- yourbranch

содержимое , связанное с новым коммитом S, является точно таким же , что и содержимое, которое вы получите, сделав коммит M, но новый коммит S имеет только одного родителя, поэтому он несвяжите три ваших коммита в ветку main-line.Теперь вы можете удалить свою ветку в будущем.Когда вы делаете это, ваши три коммита становятся невозможными для поиска, и относительно скоро Git фактически полностью их удаляет. ¹

Обратите внимание, что ваша ветвь не исчезает сама по себе.Имя yourbranch здесь поддерживает ваши первые три коммитов.Однако, если вы выполняете больше работы над своей ветвью, это не очень полезно: после того, как вы слили в сквош (и зафиксировали), вы, как правило, должны считать свою ветвь «мертвой» и удалять ее, как только ваш сквош-слияние-коммит S достаточно солидныйВозможно, вы захотите сохранить его на некоторое время, однако, в случае, если S окажется плохим, и вы или ваша группа решите вернуть S: в этом случае вы можете исправить свою собственную ветку, а затем восстановитьсделайте git merge --squash позже, используя обновленную версию yourbranch.

---

¹ Обычно, Git старается убедиться, что явно удаленные коммиты остаются как минимуммесяц или около того.Однако, если вы удалите само имя ветви, ветвь reflog , которая является одной из вещей, которая поддерживает коммиты, также исчезнет.Теперь вы полагаетесь на ваш HEAD reflog.Если вы зафиксировали коммиты в этом хранилище, это также сохранит коммиты в течение месяца или около того, но если нет, то не будет.