Как исправить фиксацию заказа в приложениях GitHub pull, разбитых на git rebase?

Когда я пишу код, я разбиваю его на небольшие логические изменения, которые легко и быстро просмотреть.

Для этого я использую git rebase -i (интерактивный), чтобы выкачать, отбрасывать и изменять порядок фиксации.

Я заметил, что это иногда приводит к другому порядку коммитов по запросу GitHub pull (хотя заказ сохраняется на удаленной ветке).

Например,

commit 1
commit 2
commit 3

может отображаться в PR как:

commit 3
commit 1
commit 2

Я искал в Интернете и только смог найти эту страницу справки GitHub: Почему мои коммиты в неправильном порядке? Их ответ:

Если вы переписываете свою историю фиксации через git rebase или push force, вы может заметить, что ваша последовательность фиксации не работает при открытии тянуть запрос.

GitHub подчеркивает Pull Requests как пространство для обсуждения. Все аспекты из них - комментарии, ссылки и коммиты - представлены в хронологический порядок. Перезапись вашей истории git commit пока выполнение перестановок изменяет пространственно-временной континуум, что означает что коммиты не могут быть представлены так, как вы ожидаете их в Интерфейс GitHub.

Если вы всегда хотите видеть коммиты в порядке, мы рекомендуем не использовать git rebase. Однако будьте уверены, что ничего не сломано, когда вы видеть вещи за пределами хронологического порядка!

Есть ли способ обойти это?

Ответ 1

Мне удалось обойти это:

Найдите последнюю фиксацию, которая сохранила заказ
Выполнить git rebase -i <hash of that commit>
Замените все pick на reword
Запустить git push -f

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

Я должен был сделать это для каждой последующей фиксации, чтобы она работала.

Ответ 2

Чтобы автоматизировать то, что предложил Элиад, я использую скрипт из Петра:

git rebase "$(git merge-base HEAD master)" --ignore-date -x 'git commit --amend -C HEAD --date="$(date -R)" && sleep 1.05'

Ответ 3

Как исправить порядок коммитов в запросах GitHub, нарушенных git rebase?

Это можно сделать с помощью (все еще обсуждаемой) команды 2019 git evolve:

Цель

Создайте команду "evolve", чтобы помочь пользователям создать высококачественную историю коммитов.

Пользователи могут улучшать коммиты по одному и в любом порядке, а затем запустить git evolve для переписать их недавнюю историю, чтобы убедиться, что все в курсе.
Мы отслеживаем изменения в коммите с течением времени в графике изменений. Пользователи могут поделиться своими прогрессировать с другими, обмениваясь их графиками изменений, используя стандартный толчок, команды fetch и format-patch.

Статус Это предложение еще не было реализовано.

Фон

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

Пока вы редактируете одно изменение, вы получаете больше отзывов об одном из других.
Что ты делаешь?

Команда evolve - это удобный способ работы с цепочками коммитов, которые на рассмотрении.
Всякий раз, когда вы изменяете или изменяете коммит, хранилище запоминает, что старый коммит устарел и был заменен новым.

Затем, в какой-то момент в будущем, вы можете запустить "git evolve", и правильная последовательность ребаз будет произведена в правильном порядке, так что ни один коммит не устарел Родитель.

Часть работы с командой "evolve" включает отслеживание изменений в коммите со временем, поэтому нам нужен график изменений.
Однако график изменений также принесет другие преимущества:

Пользователи могут просматривать историю изменений напрямую (последовательность изменений и перебазирование, которому он подвергся, ортогонально истории ветки, в которой он находится).

Можно будет быстро найти и перечислить все изменения пользователя В настоящее время выполняется.

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

Его можно использовать для украшения коммитов (в git log, gitk и т.д.), Которые либо устарели или являются вершиной незавершенного производства.

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

Это может быть использовано для корректной перебазировки локальных изменений и других локальных веток после запуска git-filter-branch.

Он может заменить нижний колонтитул change-id, используемый Gerrit.

Ответ 4

Я предлагаю псевдоним ~/.gitconfig следующим образом:

[alias]                                                                            
    rewrite = rebase -x 'git commit --amend -C HEAD --date=\"$(date -R)\" && sleep 1.05'

После того как вы выполнили свои обычные исправления rebase -i master, вы можете просто сделать git rewrite master, чтобы исправить это для порядка коммитов GitHub. Он будет создавать новый коммит каждую секунду на основе старых. Перезаписав --date, вы заставите GitHub поддерживать правильный порядок.

Ответ 5

Опция --ignore-date для rebase может использоваться для сброса даты авторизации. Это зафиксирует порядок фиксации на github.

С помощью принудительного нажатия вы можете даже зафиксировать заказ фиксации по существующему запросу на растяжение.

Например:

git checkout my_pull_request_branch
git rebase --ignore-date origin/master
git push -f origin my_pull_request_branch