5

Во время работы в команде над одним продуктом возник вопрос - как правильно и корректно подтягивать изменения других коллег с их веток или с ветки dev (основной, скажем так).

Когда я работаешь один, таких вопросов естественно не возникает и мне между двумя моими машинами было достаточно git pull - подтянуть изменения свои на одной машине - продолжить работать на другой и снова закомитить.

Так как все таки правильно? Я вижу три решения:

1) git pull - подтягиваем все изменения и работаем уже с изененными файлами из минусов вижу только то что все изменения отображаются как "мои"

2) git merge - мержить свою ветку с чужими и работать дальше

3) git cherry-pick - вносить в свою ветку коммиты коллег, которые в ветке будут отображаться как "мои" из минусов вижу только долгий и не удобный перебор всех хешей коммитов

Так вот вопрос - как все таки правльно подтягивать изменения из веток других людей?

Kromster
  • 13,809
abbath0767
  • 1,455

2 Answers2

7

Давно придумали git-flow, которое решает все вопросы. Даже есть шпаргалка.

git pull на самом деле по умолчанию делает git fetch + git merge, поэтому второй вариант включает как бы первый. git pull умеет ещё ребейзить, но этим пользуются те, кто понимает. И если отбросить мишуру, то ребейз формально делает серию git cherry-pick.

Подсумируем. Как правильно. Когда нужно сделать фичу, делаем ветку от девелопа (или мастера), делаем фичу. Если фича делается долго - поливаем изменения с ветки себе (git checkout develop && git pull && git checkout - && git merge develop) - этим упростим мердж в будущем. Когда фича готова - мержим назад в девелом (мастер). Можно напрямую, можно через pull/merge request.

KoVadim
  • 112,121
  • 6
  • 94
  • 160
4

Вопрос субъективный. Когда вам нужно опубликовать код из своей ветки в основную, у вас есть по сути четыере опции:

  • просто merge вашей ветки в основную;
  • rebase вашей ветки на head основной (линеаризация истории);
  • комбирированный вариант rebase + merge;
  • перенос патчей (cherry-pick).

Все они имеют плюсы и минусы. Выбирают, то что подходит к текущему проекту/нравится команде. Кроме того, они могут использоваться совместно в рамках сложного workflow.

Сами по себе git flow, github flow, gitlab flow и прочие flow не являются серебрянной пулей и на маленьких проектах в небольшой команде могут доставлять больше сложностей, чем удобств.

Nofate
  • 34,603