Создать ветку функций довольно просто. Однако, если вам нужно работать с ветвью коллег, нужно выполнить несколько дополнительных шагов.
Отслеживание удаленных ветвей
Мой локальный .git/, конечно, будет управлять всеми моими локальными ветвями, но мое локальное репо не всегда знает о каких-либо удаленных ветвях. Чтобы узнать, что моя локальная ветвь знает об индексе удаленной ветки, я добавляю флаг -r в git branch поэтому он вернет список:
$ git branch -r
Чтобы мое локальное репо на 100% синхронизировалось с удаленным удаленные ветки, я использую эту команду:
$ git fetch -p
-p или - флаг удаления после выборки удалит все ветки удаленного отслеживания, которые больше не существуют.
Переключение на новую ветку удаленной функции
Выполнение git pull или git fetch обновит индекс удаленных веток моего локального репо. Пока коллеги продвигают свою ветку, мое локальное хранилище будет знать эту ветвь функции.
Выполнив ветку git , вы увидите список своих локальных веток . Выполнив git branch -r , вы увидите список удаленных веток .
Процесс преобразования удаленной ветки в локальную для работы прост, просто используйте команду:
$ git checkout new-remote-feature-branch
Эта команда извлечет сведения об удаленной ветке и создаст локальный экземпляр для работы.
Сохранение актуальности с помощью основной ветки
В зависимости от того, как долго вы работали со своей веткой функций и насколько велика ваша команда разработчиков, ветвь master вашего проекта может действительно не синхронизироваться с тем местом, где вы создали ваша функциональная ветка.
Если вы завершили обновление до создания запроса на перенос, вам не только нужно быть в актуальном состоянии, чтобы объединить ваш новый код, вы также должны быть уверены, что ваш code по-прежнему будет работать с последней версией master .
Здесь проявляются некоторые альтернативные школы мысли. Некоторые команды не возражают, если вы ПОЛУЧИТЕ последнюю версию из master с помощью команды:
$ git pull origin master
Это будет извлекать и объединять любые изменения из удаленного репо в локальную ветку со всеми изменениями, что позволяет объединить вашу функциональную ветку. Это работает с целью слияния, но это довольно неприятно для графика истории ветки.
Однако другие команды не являются поклонниками этого процесса, потому что извлечение из источника может испортить ветку функции. history и усложняют выполнение более сложных функций Git. Итак, в этих ситуациях лучше всего перебазировать O_O.
Перебазирование на помощь
Перебазирование функциональной ветки не так страшно, как многие думают. Все, что делает перебазирование, — это берет обновления ветки функций и перемещает их в новое место в истории, чтобы они были поверх последней версии master ; то есть это как если бы вы только что создали эту функциональную ветку и внесли обновления. Это создает очень согласованную историю ветвей, за которой легко следить и с которой легко работать в любых ситуациях.
Чтобы перенастроить локальную ветвь функций из последней версии master , выполните следующие действия.
$ git checkout master/* убедитесь, что вы находитесь в главной ветке */$ git pull/* получите последнюю версию с пульта */$ git checkout my-feature-branch/* проверка ветки функций */$ git push origin my-feature-branch/* обновление вашей копии в репозитории */$ git rebase master/* перебазирование в основной ветке */$ git push origin my-feature-branch --force/* принудительное обновление удаленного */
И все. Этот процесс гарантирует, что у вас установлена последняя версия master , вы берете коммиты из вашей функциональной ветки, временно снимаете их, перемещаете их в последнюю версию master branch, а затем повторно зафиксировать их. Пока нет конфликтов, проблем быть не должно.
Принудительно нажать? Но…
Да, есть и те, кто не любит принудительное продвижение, но в случае с функциональной веткой это нормально. Однако принудительное нажатие на master — это действительно плохая идея.
При выполнении таких операций, как перемещение, вы (фактически ) изменение истории ветки. Когда вы это сделаете, вы не сможете нажать на пульт, так как истории конфликтуют, и вы получите отказ. Чтобы решить эту проблему, добавьте флаг - force , чтобы принудительно нажать, чтобы указать удаленному устройству игнорировать эту ошибку и заменить предыдущую историю новой, которую вы только что создали.
Конфликты
В худшем случае возникнет конфликт. Это произойдет, даже если вы вытащили непосредственно из master в ветку функции. Чтобы разрешить конфликт, прочтите отчет об ошибке в командной строке. Это сообщит вам, в каком файле есть конфликт и где он находится.
При открытии файла вы увидите преднамеренный разрыв содержимого файла и две части, которые по сути являются дублируется, но немного отличается. Это конфликт. Выберите одну из версий и удалите весь синтаксис конфликта, введенный в документ.
Как только конфликт (ы) разрешен, добавьте следующее исправление обратно в командную строку:
$ git add.
После постановки новых обновлений вы не можете выполнить повторную фиксацию, поскольку этот процесс находится внутри предыдущей фиксации.. Итак, вам нужно продолжить перебазирование:
$ git rebase --continue
Если по какой-либо причине вы застряли внутри перебазирования, которое вы просто не можете понять, вы можете отменить перебазирование:
$ git rebase --abort
Пока нет других проблем, перебазирование будет продолжаться, а затем завершится выводом обновлений.
