Поддержание чистоты в истории git с сохранением журнала изменений для проверки кода

Question

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

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

Предоставляет ли git инструменты для просмотра изменений, вызванных перебазированием, или существует альтернативный рабочий процесс, который позволяетgit history содержит отдельные коммиты на изменение без дополнительных фиксаций «Fixes», но все же позволяет рецензентам видеть каждое изменение, как код находился на стадии PR.Для контекста я использую bitbucket, но мне было бы интересно, могут ли это сделать raw git или другие сайты.

Answer 1

Так что я надеюсь, что понял то, что вы только что описали.Из того, что я понимаю, в основном после того, как рецензент публикует комментарии по запросу-запросу (PR), разработчик обновляет указанный коммит, а затем после его нажатия вы все равно увидите только один коммит (в котором он новый и обновленный послеисправление, и исходный коммит «пропал»).Да?

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

develop   o---o---o
                   \
feature             A

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

develop   o---o---o
                   \
feature             A---A'

с A 'как' исправление 'после комментария рецензента.Вы можете проверить дельту от A 'до A, вызвав:

git diff hashidAprime hashidA

Я бы предложил перебазировать ветку только при обновлении из Develop / trunk.Не перебазируйте, когда вы все еще работаете.Теперь, если вы попали в ловушку того рабочего процесса, в котором вы строго один коммит на функцию перед PR, я советую каждый раз, когда вы делаете исправление, вы просто отмечаете это в сообщении коммита.Вид журнала изменений, если вы можете.Но это только показывает описания того, что изменилось, а не блоки кода, которые были затронуты.Я бы лично выбрал только фиксацию и фиксацию каждый раз, когда есть обзор.Он все равно будет выглядеть аккуратно, вам не обязательно быть строгим в отношении одного коммита, если вы спросите меня.

Answer 2

Нет собственного решения (GitHub, BitBucket или GitLab).

GitHub PR хранит ссылку на старую историю (перед каждой перебазировкой), но сравнивать старую с новой историей слишком громоздко.

Альтернативой может быть поощрение разработчика перебазировать / уточнитьистория:

• только на конце процесса проверки, для окончательного тестирования, до принятия ПР.
• не во время процесса проверки, гдевозникнет проблема, сформулированная в вопросе ОП.