Есть ли способ игнорировать локальную историю коммитов при слиянии и удалении?

Question

Мы хотим иметь ветки для разработчиков на git.Другими словами, разработчики должны были разветвляться из ветви «разработка» и создавать собственную локальную ветку «функции» для работы.

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

Если вы сделаете git log --graph, ветки «feature» не будут отображаться, чего мы и хотим.Однако каждый коммит, который разработчик сделал , теперь отображается в ветви devel.Это безобразноЕсли есть 10 разработчиков, и каждый из них сделал 30 коммитов в своей ветви функций до того, как все они были объединены в devel, devel теперь показывает историю 180 коммитов в общей сложности 6 функций.Было бы лучше, если бы история только показывала сообщения для 6 слияний в devel.

Есть ли какой-нибудь способ избежать создания "грязной" истории и игнорировать историю локальной ветви при слиянии? Или это просто слишком много борьбы с мерзавцем?

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

Answer 1

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

Не делай этого.

Сделай первый черновик в своем местном репо¹.Затем полностью переписайте этот первый черновик истории для публикации, git rebase -i - это обычная команда, рекомендованная для этого, но я обнаружил, что git reset --soft с последующими git add --patch s удобнее для создания истории просмотра, которая подходит дляобщественное потребление.Затем полностью переработайте его, так как обратная связь делает очевидными любые ошибки, и опубликуйте / объедините чистый результат.

Первая серия коммитов, локальная для репозитория разработчика, не более полезна для других, чем считывание ихРедактор отмены буфера истории.Фактически, это то, что по сути представляет собой первый черновик истории Git: буфер отмены редактора всего проекта, с примечаниями, которые помогут с неизбежным на следующей неделе "о чем я думал ?"вопросы.Никому больше не нужно это видеть.Это заметки на вашем рабочем столе, рабочий продукт, предназначенный для мусорного бака при рождении.

---

^{¹ хорошо иметь репозиторий на болоте, где разработчики могут продвигать свои WIP-материалы для наглядности иВ сотрудничестве, важно не рассматривать истории WIP как что-то, кроме записок, которые можно отбросить, независимо от того, у кого есть копия.То, как вы управляете ими, очень, очень отличается от того, как вы управляете всем, что было запущено в производство}

Answer 2

Если вы сделаете git log, ветки «feature» не будут отображаться, чего мы и хотим. Тем не менее, каждый коммит, который сделал разработчик, теперь отображается в ветке devel.

git log по умолчанию показывает линейную версию истории, которая является простой и ложной. История Git не линейна. Ветви действительно ветвятся.

Вместо этого ...

A - B - C - D - E - F - G - H [devel]

Ваша история действительно выглядит так.

A ---------- E ----- H [devel]
 \          / \     /
  B - C - D    F - G

Это можно увидеть с помощью git log --graph или инструмента визуализации Git, например Gitup .

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

Есть ли какой-нибудь способ избежать "запутывания" истории и игнорировать историю локальной ветви при слиянии? Или это просто бои с мерзавцем?

Мой совет - привыкнуть к нему и научиться ориентироваться в нем. Например, git log --merges будет отображать только коммиты слияния. Хороший инструмент визуализации Git очень поможет.

Другой способ - побудить разработчиков очистить свои ветки перед их фиксацией. Если у вас есть много коммитов, которые "исправляют опечатку" и "упс" и "не прошли тесты", они не будут иметь большого значения в будущем. Они могут использовать git commit --amend для изменения предыдущего коммита и git rebase -i «fixup» для объединения существующих коммитов вместе . Это гарантирует, что все коммиты имеют какое-то значение.

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

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

То, что вы видите как "грязный", является ценным пониманием , почему код был написан таким, какой он есть. Это золото для всех, кто работает с кодом в дальнейшем. Разобравшись, его никогда не восстановить.

Answer 3

Есть ли способ избежать "запутывания" истории и игнорирования истории локальной ветви при слиянии? Или это просто борьба с мерзавцем?

Абсолютно. Просто не сливай ничего. Сделайте публичное репо, где вы по отдельности выбираете коммиты. Один из способов сделать это - использовать систему отзывов, например, Gerrit.

Сбор вишни гарантирует, что у вас будет чистая линейная история без беспорядка слияния.

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

Следует поощрять то, что разработчики очищают свои ветви функций перед слиянием. Например, не имеют коммитов, которые просто исправляют тривиальные ошибки компилятора («Забудьте точку с запятой в parse_descriptor, упс!»). Или фиксирует тот код для «очистки», который был изначально испорчен только той же самой функцией разработки. Передача "не по теме" в ветку функций также не рекомендуется.

Хорошее правило для принятия заключается в том, что каждый коммит должен быть построен; ни один коммит не должен нарушать что-либо такое, что требует последующей фиксации. Такие коммиты должны быть сведены вместе.

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