Наш код находится на Github, и мы используем Pull Requests для просмотра кода. В результате проверки фиксация может быть отменена или изменена. Это может загромождать историю фиксации. Команда rebase обескуражена, потому что коммиты уже «общедоступны».Как сохранить чистую историю после просмотра GitHub Pull?
Если вы выполняете обзоры кода аналогичным образом: как вы справляетесь с этим? Как вы сохраняете свою историю чистой?
Регенерация не-магистра (maint *, next) ведется нормально, даже если они опубликованы. Просто используйте ветви темы для публикации новых материалов, подлежащих рассмотрению. Затем удалите их в любом случае после их объединения в мастер или после отклонения запроса на перенос. См. man gitworkflows
Я бы предложил просто перехватить историю фиксации.
Имейте в виду, что, когда вы смотрите на историю, вы обычно смотрите на родословную какой-либо текущей фиксации. Если ваш процесс проверки кода создает тупиковые ветви для кода, который был отклонен или повторно отправлен в качестве другой фиксации, тогда они не будут в какой-либо такой родословной и обычно не будут видны.
Вот многословно, но полный пример этого, используя git log в качестве зрителя истории:
$ git init example
Initialized empty Git repository in /private/tmp/example/.git/
$ cd example/
$ date >date
$ git add date
$ git commit -am base
[master (root-commit) 5108762] base
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 date
$ date >date
$ git commit -am bad
[master 440c3b6] bad
1 files changed, 1 insertions(+), 1 deletions(-)
$ git log
commit 440c3b61b279e8b7cd5f5f656984b63ba18e518b
Author: Tom Anderson <[email protected]>
Date: Sat Mar 10 09:15:48 2012 +0000
bad
commit 5108762ba7011464fe3c57cf762d0d18f337f68c
Author: Tom Anderson <[email protected]>
Date: Sat Mar 10 09:15:28 2012 +0000
base
$ git branch postreview 5108762ba7011464fe3c57cf762d0d18f337f68c
$ git checkout postreview
Switched to branch 'postreview'
$ date >date
$ git commit -am good
[postreview 42e5257] good
1 files changed, 1 insertions(+), 1 deletions(-)
$ git log
commit 42e5257addf73b516676d24e7092b0e4768d3564
Author: Tom Anderson <[email protected]>
Date: Sat Mar 10 09:17:30 2012 +0000
good
commit 5108762ba7011464fe3c57cf762d0d18f337f68c
Author: Tom Anderson <[email protected]>
Date: Sat Mar 10 09:15:28 2012 +0000
base
Даже несмотря на то, плохой фиксации в хранилище, оно не отображается в выходных данных журнала мерзавец , В этом случае я создал новую ветку для выполнения моей работы после обзора, но на практике вы, вероятно, хотите переместить мастера для новой работы, оставив старую работу на мертвой ветке.
Если я правильно верну свой пример, это работает только для последней фиксации. Или? В противном случае мне, вероятно, нужно заглянуть в 'postreview'? –
Я думал, что вы начнете новую ветку с того момента, прежде чем приступить к написанию просматриваемого кода, возможно, несколько коммитов вернутся, так что да, вы бы выбрали все, что захотите, чтобы перейти к новой ветке. Это в основном то же самое, что и rebase, но с некоторыми изменениями в совершении на этом пути, а не с удалением старых коммитов. Фактически, вы могли бы сделать это как перебазировку. –
Я пробовал оба подхода, и это отлично работает для меня. Благодаря! –