Последствия коммита в будущем
Я случайно зафиксировал и отправил изменение на пульт, в то время как дата моего устройства была установлена на несколько дней в будущем (т. Е. Дата установлена на 23-е вместо 21-го).
Я сослался на это, которое решит мою проблему, но посоветовал не выполнять его из-за силового толчка.
Итак, мой вопрос заключается в том, что сохранение неправильной даты и времени фиксации негативно повлияет на репозиторий Git (локальный и удаленный). Я использую «Git Lab» в качестве поставщика удаленного репозитория.
@Dai, насколько я понимаю, вы говорите, что это не проблема, пока не выполняется rebase
Нет, я говорю, что это совсем не проблема, потому что rebase в git — очень распространенная операция.
Хорошо, спасибо за разъяснение.
Ответы 2
но посоветовал не выполнять его из-за силового толчка.
Любая перебазировка потребует принудительного нажатия для публикации перебазированной ветки.
Но это проблема только в том случае, если это делается в общедоступной ветке, над которой работают несколько соавторов.
Если это ваша собственная рабочая/тематическая ветка, вы можете перебазировать/форсировать нажатие столько раз, сколько захотите.
На самом деле это делается перед запросом на включение , чтобы обеспечить легкое слияние сопровождающим (или сопровождающий может инициировать перебазирование самостоятельно).
Итак, мой вопрос: будут ли сохранены неправильные дата и время фиксации отрицательно повлиять на репозиторий Git (локальный и удаленный). Я использую «Git Lab» в качестве провайдер удаленного репозитория.
Ответ: "это зависит". С точки зрения git это не так: дата записывается как метаданные, а порядок фиксации предоставляется на основе отношений родитель/потомок. Пожалуйста, смотрите этот ответ для дальнейшего изучения.
Однако, если вы используете CI-скрипты или внимательно следите за фактической историей репозитория, запись неправильных метаданных — это плохо в широком смысле. Это можно исправить.
Кстати, вы можете делать много чего с метаданными, например, помимо прочего, создавать коммиты в прошлом.
Совершение
Окончательное создание объекта коммита Git обычно выполняется с помощью git-commit-tree, который использует эти переменные среды в качестве своего первичный источник информации, возвращаясь к значениям конфигурации только если их нет.
GIT_AUTHOR_NAME— удобочитаемое имя в поле «автор».
GIT_AUTHOR_EMAIL— адрес электронной почты для поля «автор».
GIT_AUTHOR_DATE— временная метка, используемая для поля «автор».
GIT_COMMITTER_NAMEзадает человеческое имя для поля «committer».
GIT_COMMITTER_EMAIL— адрес электронной почты для поля «коммиттер».
GIT_COMMITTER_DATEиспользуется для временной метки в «коммиттере». поле.
user.emailзначение конфигурации не задано. Если это не установлено, Git возвращается к имя системного пользователя и хоста. источник
Это еще одна очень хорошая ссылка для понимания внутренностей git:
Давайте немного рассмотрим хэши этих объектов. Скажем, я написал строку
git is awesome!и создал из нее большой двоичный объект. Ты сделал то же самое в вашей системе. Будет ли у нас такой же хэш?Ответ — Да. Поскольку большие двоичные объекты состоят из одних и тех же данных, они имеют одинаковые значения SHA-1.
Что, если я сделаю дерево, которое ссылается на каплю
git is awesome!, и дал ему определенное имя и метаданные, и вы сделали то же самое на ваша система. Будет ли у нас такой же хэш?Опять же, да. Поскольку объекты деревьев одинаковы, они будут иметь тот же хэш.
Что, если я создам фиксацию этого дерева с сообщением фиксации
Hello, и вы сделали то же самое в своей системе. Будет ли у нас такой же хэш?В этом случае ответ — Нет. Несмотря на то, что наши объекты фиксации ссылаются к одному и тому же дереву, у них разные детали коммита — время, коммиттер и т. д. источник
Вообще говоря, нет. Некоторые плохо написанные инструменты, предполагающие строго хронологический порядок, могут запутаться, но в Git все, что имеет значение, — это ссылки на коммиты
parent. Тем не менее, git в любом случае был разработан для хронологически переупорядоченных коммитов — вот как выrebase.