Как одна копия фиксируется без создания разных SHA1?

Question

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

1. Не merge, если это не имеет смысла. Вместо этого используйте rebase.
2. Если вам просто нужно втянуть один фиксатор, cherry-pick - твой друг.
3. Всегда pull --rebase на пульте дистанционного управления перед тем, как нажимать.
4. Хранить функции в соответствии с rebase.

Что они не говорят вам, это общепринятая создает кучу фиксаций, которые почти идентичны, за мелкие детали, которые меняют свои SHA1s кроме. Почему это имеет значение? Это поражает цель сравнения ветвей с git log --left-right --graph --cherry-pick --oneline branch1..branch2 и git show-branch, что особенно раздражает. Почувствуется как дешевого разветвления. Это почти невозможно увидеть, какие патчи отсутствуют в каждой ветке.

Итак, как вы поддерживаете несколько ветвей в соответствии с идентичными SHA1, чтобы эти инструменты могли использоваться? Являются ли заплатки лучшим способом сделать это?

Answer 1

Вы не можете держать коммиты с одинаковыми ПОР в нескольких местах, так как «место» коммит (его расположения в истории) идентифицируется SHA.

A Git commit содержит определенные данные, в том числе моментальный снимок текущего состояния репо, текущее время и дату, имя участника и адрес электронной почты, и SHA родительского фиксатора.

Это означает, что когда вы поставите совершить где-то еще (rebase, cherry-pick, патч + применить) или изменить свое время (commit --amend), Ша будет отличаться.

Это значительная особенность Git (история Git - это так называемый Merkle tree).

Как вы заметили, вы можете поддерживать (content-) эквивалент совершает, используя различные команды перезаписи истории, упомянутые выше.

---

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

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

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

Answer 2

Я не думаю, что это обычная мудрость, чтобы не сливаться, если она не имеет смысла. Если вы хотите сохранить историю с идентичными хэшами SHA1, слить и избежать выбора вишни.