Каковы практические последствия переписывания истории Git?

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

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

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

  • Если я перепишу историю (и все будет компилироваться / работать во всех затронутых ветвях), нужно ли будет моим коллегам выполнять какие-то специальные команды? (Другими словами, «узнают ли они, что я сделал это», если я сделал это хорошо?)
  • Могут ли какие-либо пользователи с локальными изменениями, о которых я не знаю, иметь право на ошибки слияния на git pull?
  • Я упустил здесь что-нибудь существенное?

Любые ссылки на статьи / учебные пособия по этой теме также были бы очень хороши.


person krosenvold    schedule 29.09.2009    source источник
comment
@Goober: Наивный ответ от меня, это проблема? Мы прошли испытания, поэтому я верю, что мы его поймем.   -  person krosenvold    schedule 29.09.2009


Ответы (2)


Обязательное чтение: Проблемы с перезапись истории в Руководстве пользователя Git.

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

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

Могут ли какие-либо пользователи с локальными изменениями, о которых я не знаю, иметь право на ошибки слияния при git pull?

Обязательно, см. Выше.

Я упустил здесь что-нибудь существенное?

Избегайте переписывания истории (почти) любой ценой!

person Greg Hewgill    schedule 29.09.2009
comment
Я действительно прочитал эту часть руководства, такое ощущение, что я прочитал все руководства RSN;) Всегда ли переписанные ветки получают новые идентификаторы? Это действительно объясняет, почему этого никогда не следует делать ... - person krosenvold; 29.09.2009
comment
Из-за того, как Git идентифицирует коммиты по их содержимому и всем предыдущим коммитам, любое изменение (пусть даже незначительное) коммита будет выглядеть как совершенно новая ветвь разработки для Git. Невозможно сделать так, чтобы переписанная история выглядела почти так же. - person Greg Hewgill; 29.09.2009
comment
Спасибо, странно, как просто отсутствие крошечной информации в git может иметь большое значение. - person krosenvold; 29.09.2009
comment
Это широко считается функцией формата репозитория Git. Что, если эта крошечная информация была критически важна? См .: keithp.com/blogs/Repository_Formats_Matter для отличной публикации по этой теме. - person Greg Hewgill; 29.09.2009
comment
Извините, я не совсем понимаю: я не понял, что при переписывании histroy нужно создать производную ветвь. Теперь, когда я знаю, что у меня больше нет вопросов без ответов о перезаписи истории;) Я понимаю, что полностью отказываюсь от любых ветвей функций, созданных после точки перезаписи. - person krosenvold; 29.09.2009
comment
Теперь я понимаю вашу позицию. Рад, что теперь это имеет смысл! - person Greg Hewgill; 29.09.2009

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

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

Это приводит нас к паре веских причин переписать историю:

  • Уменьшите частный репозиторий перед тем, как стать публичным: например, создайте новую локальную частную ветку, протестируйте, протестируйте, переписайте, нажмите.
  • Перед публикацией удалите конфиденциальные данные из частного репо.

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

И есть, по крайней мере, еще одна философская и упускаемая из виду причина: переписанная история - это потеря данных. Правда, история git с revert может выглядеть более запутанной, чем reset. Но при правильном написании весь этот «беспорядок» можно спрятать в отдельных ветвях, и все же мы можем точно увидеть, в какой момент был выполнен откат. И даже с указанием причин или доказательств того, почему это было сделано.

Вернемся к аналогии с деревом: даже если вы удалите поддерживающее бревно, перевернутая ветка покажет извилистые растущие кривые, и это прекрасно!

person cregox    schedule 17.09.2013
comment
Обратите внимание, что есть более новое (2-е) издание главы «История перезаписи». git-scm.com/book/en/v2/Git- Инструменты-Перезапись-История - person Randall; 28.04.2016
comment
Я согласен посоветовать людям учиться и судить, как взрослые, когда делать что-то - хорошая идея. Переписывание истории, которое часто делается в ветках функций, которые (пока) не должны выполняться другими, является обязательным и обязательным для нашей компании. - person Xavier Arias Botargues; 23.11.2017
comment
@XavierAriasBotargues, возможно, это действительно самое привлекательное повседневное использование для переписывания: на практике намного проще просто очистить материал и удалить много бесполезного беспорядка при самостоятельной разработке. и очень мало или вообще нет никакой выгоды в том, чтобы делать лишнюю милю, чтобы сохранить эту историю в любом случае. тем не менее ... я надеюсь, что ваша компания не закроет те, которые вернутся. ;П - person cregox; 07.12.2017