Лучшая практика для работы в местном филиале + PR на основе другого местного филиала + PR - PullRequest
0 голосов
/ 12 декабря 2018

Я пытаюсь определить лучший рабочий процесс для работы с несколькими филиалами и PR, которые могут основываться друг на друге.Я просто хочу знать, каковы лучшие практики, особенно в отношении перебазирования в этом случае, чтобы я не попал в плохое состояние.Вот более или менее то, что я делаю до сих пор, с некоторыми из описанных сценариев.Пожалуйста, дайте мне знать, что было бы лучше:

Я работаю с github, у меня есть мастер-репозиторий origin на github, а также мой собственный репозиторий.Я нажимаю на свое пользовательское удаленное репо и превращаю PR в исходное главное удаленное репо.

 git checkout master
 git checkout -b branch_first
 .. do some work ...
 git commit
 git push remote
 # Make a PR on github for branch_first, to merge it into the origin master branch

 # While I wait for comments/review on branch_first, start to 
 # Work on branch_second
 git checkout -b branch_second  # This branch is based off first
 .. do some work ...
 git commit
 git push remote
 # Make a PR on github for branch_second, to merge it into the origin master branch

 # Got some review comments, checkout branch_first and make some changes
 git checkout branch_first
 .. do some work ...
 git commit
 git push remote # Possibly repeat this, or ask the committer to merge when done.

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

Время от времени вам нужно фиксировать фиксации фиксации, чтобы поддерживать связь с общественностью в чистоте и легко просматривать.Поэтому я запускаю что-то вроде этого на скажем branch_second.

rebase -i HEAD~10
# change commits to fixup or squash and save.

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

Иногда мне нужно получить файлы кода, которые я изменил во времяобзор кода branch_first в branch_second

rebase branch_first

Насколько я понимаю, это может работать некорректно все время?Я думаю, что иногда это приводит меня в плохое состояние.Некоторые коллеги говорили мне, что это может быть более подходящим для запуска на branch_second

git rebase --onto master branch_first branch_second

Иногда мне нужно снова получать файлы из источника master.Поэтому я запускаю это на branch_first или branch_second.

git fetch origin master
git rebase origin/master

Иногда, когда я запускаю команды rebase, я теряю происхождение, у меня есть коммиты, которые я хочу в основном, но я не вижу branch_first в журнале gitистория коммитов, которые я ожидаю.

1 Ответ

0 голосов
/ 13 декабря 2018

git rebase -i HEAD~10 когда значение параметра branch_second приведет к расхождению branch_first и branch_second, если HEAD ~ 10 старше, чем общий предок двух ветвей.Это может привести к тому, что вы не увидите branch_first в истории коммитов branch_second.Лучше всего когда-либо перебазировать branch_second на branch_first.

rebase branch_first, когда на branch_second получить коммиты из вашего PR branch_first в branch_second, это довольно распространенный рабочий процесс, который не должен вызывать каких-либо странных ошибок.

git rebase origin/master когда на branch_second в основном делает копии (с разными идентификаторами коммитов) всех коммитов на branch_second вплоть до общего предка branch_second и origin / master.Поскольку branch_first по-прежнему связан со старыми коммитами (которые были только что скопированы), он не будет отображаться при просмотре истории branch_second после этой перебазировки.

Я бы предложил прочитать this статья, чтобы построить больше интуиции для того, что git rebase делает.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...