git комментирует сжатый коммит
Я всегда скептически относился к "раздавливанию" или переписыванию истории, и теперь я почти уверен, что должен запретить эту практику в репозиториях, которыми я управляю. Но, может быть, кто-то может ответить на это и сэкономить день для моих коллег-чемпионов по сквошу.
Я только что наткнулся на строку кода, которую я хочу понять обоснование, поэтому я использовал git annotate узнать, кто это написал и почему. Но это указывает на "сжатый" коммит, длинный список заголовков сообщений коммитов о множестве функций и исправлений ошибок, без подробностей. Не очень полезно.
"О, но всегда есть рефлог", - я был уверен; "Информация никогда не теряется в Git!" Хорошо, рад это слышать! Но я пытался git reflog <squashed-commit-hash>и не получил никакого вывода - не полезно. Я тоже пробовал git rev-list <squashed-commit-hash>и получил список из сотен хешей, а после проверки вручную нескольких из них git showЯ пришел к выводу, что они не являются частью того, что было раздавлено - тоже не полезно.
Так возможно ли на самом деле узнать, какой отдельный коммит внес вклад в эту строку кода, и увидеть все сообщение этого коммита? Можно ли это сделать одной командой git без необходимости быть гуру Баш? Или эта информация, на самом деле, фактически была потеряна в Git?
3 ответа
Так как другие ответы не обращались к этому, я думаю, что это должно быть вызвано:
"О, но всегда есть рефлог"
№ 100% ложь. Рефлог является как локальным, так и временным.
Это правда, что git очень хорошо защищает от потери истории (если вы специально не указали, что она теряет историю), но сказать, что информация никогда не теряется, крайне неточно и опасно. Люди должны понимать, как информация может (и не может) быть потеряна, чтобы они знали, когда и как полагаться на средства защиты, которые действительно предлагает git.
Что касается более широкой проблемы:
Переписывание общих историй обычно не является хорошей практикой. Большинство людей, которые выступают за агрессивные перебазировки, хотят переписать истории, прежде чем отправлять их на удаленный компьютер. Это не только непопулярная практика, но и запретить ее практически невозможно, даже если вы захотите (потому что, когда я нажимаю коммит, вы не знаете, создал ли я его, раздавив несколько предыдущих коммитов или нет).
Приемлемая детализация окончательных коммитов и приемлемая документация для каждого коммита - это стандарты, которые вам нужно установить с командой. Правоприменение, вероятно, в конечном итоге будет скорее социальным, чем техническим.
Сжатие коммита превращает множество коммитов в один, давая коммитеру возможность поддерживать сообщение коммита для каждого отдельного коммита.
Если они решили не делать этого, то нет способа разглядеть информацию об отдельных коммитах, которые были объединены в один.
Я должен подчеркнуть:
Я был уверен; "Информация никогда не теряется в Git!"
Это относится только к файлам в Git, который часто является исходным кодом. Естественно, когда кто-то переписывает историю, все ставки выключены.
Поскольку вы можете видеть, кто совершил работу, лучше всего получить больше информации об этой конкретной строке кода, чтобы провести с ними проверку кода. Если они больше не работают с вами, то все, что вам нужно, - это весь сдавленный коммит.
Так возможно ли на самом деле узнать, какой отдельный коммит внес вклад в эту строку кода, и увидеть все сообщение этого коммита?
Что касается истории вашего проекта, то "одиночный коммит" - это сдавленный коммит, так что именно это и будет отображаться как источник изменения кода. Это сделано намеренно, и практическая цель состоит в том, чтобы объединить несколько коммитов в один для сохранения управляемости истории git. Вот пример того, когда я бы использовал коммит на проекте:
Я работаю над функцией среднего размера. Это займет пару дней. У меня есть тенденция совершать довольно регулярно, так как "работа в процессе" (WIP) фиксируется и всегда в конце дня. Мои коммит-сообщения часто относятся к текущей функции, над которой я работаю, а не к проекту в целом. Как только функция завершена, и я сливаюсь в какую-либо рабочую ветвь (скажем, dev), эти сообщения трудно проанализировать в контексте проекта, и различия между коммитами, которые я сделал в ветви функций, на самом деле не имеют значения для удобства сопровождения., Различия, которые имеют значение, относятся к функции "против" и "после", поэтому я объединю все свои коммиты в одну, помеченную как "(номер тикета) - (имя функции)"