Рабочий процесс интегратора, действительно ли переосновное нажатие выборки безопасно для удаленного repos?
Существует свободный скринкаст, доступный из iDeveloperTV Сети
5 ответов
Вы определенно не хотите делать то, что вы предлагаете, это переустановит ветвь master на master вашего коллеги. В зависимости от того, на чем был основан мастер вашего коллеги, вы можете часто перематывать центральный мастер .
Возможно, вы захотите сделать обратное, переустановите мастер своего коллеги перед объединением это в мастер.
git fetch coworker
git checkout coworker/master
git rebase master
git checkout master
git merge HEAD@{1}
git push
Я все же не рекомендовал бы это. Ваши коллеги должны будут решить, как вы перебазируете их изменения. В большинстве случаев это, вероятно, тривиально, и они могут выбросить свои коммиты в пользу ваших, но им, вероятно, все равно придется проверять это вручную.
Лично я бы рекомендовал прямое слияние их коммитов. Если вы чувствуете, что они основаны на слишком старой версии мастера и слияние будет излишне сложным или основано на неоправданно старом коммите, тогда попросите их перебазировать свой мастер и выполнить повторную выборку. Тогда по крайней мере они знают, что вы объединяете, и разрешают любые конфликты в своем коде.
Кроме того, я бы предостерегал от стремления к излишне линейной истории. Объединение ветвей разработчиков, разрабатываемых параллельно, дает более точное представление об истории. Если вы перебазируете фиксацию разработчика перед слиянием, то у вас больше не будет записи фиксации, которая точно отражает состояние кода, который этот разработчик исправил и отправил. Это может не иметь значения очень часто, но может случиться так, что два коммита взаимодействуют, создавая ошибку, но не конфликт слияния. Если вы не перебазируете, вы получите более точный (и более справедливый!
Подавляющее большинство огромного количества документации и руководств по git ясно дают понять, что rebase следует использовать только в частных ветвях, а не в том, что кто-то может увидеть. По вашей модели я бы очень боялся необъяснимых сбоев или повторения работы на других репликах. Избегайте!
Это приемлемый рабочий процесс для тривиальных случаев. Когда ваши коллеги выполняют git pull , на самом деле это git fetch , за которым следует git merge . Git действительно хорош в выполнении слияний и сможет решить простые случаи без проблем.
Однако, если вам нужно выполнить какую-либо работу по разрешению конфликтов на этапе git rebase , то ваши коллеги могут иметь чтобы проделать эту работу снова , когда они тянут. Это произойдет, потому что ваша последовательность коммитов после перебазирования будет сильно отличаться от их.
Если вы освоитесь с нелинейной историей, Git, вероятно, сможет лучше управлять этим рабочим процессом (поскольку именно для этого он предназначен) .
Как упоминалось в статье « Перемирие в войне слияния и перебазирования? » (выделено мной)
Возможно, самая большая проблема с традиционным перебазированием заключается в том, что он предотвращает сотрудничество .
Тот, кто извлекает данные из репозитория до и после перенастройки, будет испытывать конфликты, потому что эти две истории противоречат друг другу. Таким образом, стандартное предостережение «не переустанавливайте в опубликованном репозитории», которое можно переформулировать на «не сотрудничать в работе, которую вы, возможно, позже захотите переустановить».
Даже если это «работает» из-за отсутствия конфликтов , это может привести к некоторым проблемам, если вам придется решить какое-либо нетривиальное слияние во время перенастройки:
M0----M1----M2
\
\
\
B1----B2
M0----M1----M2
\
\
\
B1'---B2'
SHA-1 вашей (ранее опубликованной) ветки переписывается, вашим коллегам будет трудно объединить эту ветку в свои окружающая среда.
Я провел несколько простых тестов в этом рабочем процессе. Я согласен с сообщением Чарльза, но хотел добавить другую информацию.
Плюсы
- Рабочий процесс не нарушит работу пользователей, извлекающих из вашего публичного репозитория.
- Это дает вам больше контроля над коммитами, втягиваемыми в ваше хранилище. mainline.
- Легче следить за историей функций ветки mainline. Если вам нужно выполнить фиксацию слиянием (стандартный рабочий процесс) для внесения нескольких изменений, тогда фиксация слияния сгруппирует модификации всех новых коммитов в одну фиксацию. Это нарушает идиому «одна фиксация - одна функция».
Минусы
- В репозитории, из которого вы извлекаете изменения, «исходные» коммиты все равно будут отображаться. Это, скорее всего, запутает участника, если он не знает, что вы делаете. Я предполагаю, что один из способов обойти это - заставить участника выбросить свою dev-ветку после того, как вы ее вытащите и переустановите.
- Если удаленные репозитории не выбрасывают свои dev-ветки после переустановки, тогда это делает историю основной ветки трудно следить за удаленной веткой.
- После перебазирования вы теряете исходное имя автора в коммите. (Хотя, возможно, есть ручной способ обойти это.) Это затрудняет отслеживание того, кто внес каждое изменение.