Правильная схема рабочего процесса git с несколькими разработчиками, работающими над одной задачей

Я лидер команды в нашей компании веб-разработки, и я хотел бы реализовать git workflow в нашей команде. Чтение документации и статей я нашел следующую структуру, хорошую для нас:

У нас есть хранилище в Bitbucket. мастер ветвь считается содержащей только стабильный код. Каждый разработчик должен создать свою собственную ветку и реализовать функции / исправления в своем собственные филиала. Как только он решает, что его код готов, он создает хорошую ветку история (используя rebase, amend, cherry-pick etc.) и толкает его в Bitbucket, где создает запрос на вытягивание для master branch. QA проверяет функциональность и одобряет (или не одобряет) ее, затем я проверяю код, и если все в порядке, я объединяю его работу в master (путем быстрой перемотки вперед или перезагрузки для лучшей истории коммитов).

но эта схема хороша только в том случае, когда на ветке работает один разработчик. В нашем случае у нас почти всегда есть два разработчика для одной отрасли, так как один разработчик работа над на стороне сервера (PHP), а другой - на стороне клиента (HTML / CSS / JS). Как эти два должны сотрудничать таким образом, чтобы история фиксации в master оставалась чистой?

Server dev создает базовую структуру HTML-файлов, и клиент dev должен получить эту структуру. Логично было бы для server dev создать ветку, а для client dev создать свою собственную ветку, основанную на ветке server dev. Но это означает, что server dev должен публикации его филиал в Bitbucket, который сделает его невозможно для него, чтобы переместить или изменить совершает, которые уже опубликованы.

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

Как вы справляетесь с таким сотрудничеством в своих рабочих процессах?

35
bitbucket branching-and-merging git workflow

7 ответов

Я не могу говорить о достоинствах методов, описанных в вашем посте, но я могу описать, как мы решили совместное кодирование в рабочем процессе, который мы используем на работе.

рабочий процесс, который мы используем, является одной из многих ветвей. Наша структура такова:

мастер золотой; только мастер слияния касается его (подробнее об этом немного).

есть ветвь dev, взятая изначально от master, что все разработчики работают. Вместо того, чтобы иметь филиал на разработчика, мы делаем функция, или билет, филиалы от dev.

для каждой небезрассудной характеристики (ошибки, повышения, etc.), новая местная ветвь сделана от dev. Разработчикам не нужно работать в одной ветви, поскольку каждая ветвь функций ограничена только тем, над чем работает один разработчик. Вот где дешевое ветвление git пригодится.

Как только функция готова, она локально объединяется обратно в dev и подталкивается к облаку (Bitbucket, Github и т. д.). Все синхронизируются часто дергал Дэва.

мы находимся на еженедельном графике выпуска, поэтому каждую неделю, после того, как QA одобрил ветку dev, ветка выпуска производится с датой в названии. Это филиал, используемый в производстве, заменив ветку выпуска на прошлой неделе.

Как только ветвь выпуска проверяется QA в производстве, ветвь выпуска объединяется обратно в master (и dev, просто для безопасности). Это единственный раз, когда мы касаемся мастера, гарантируя, что он чист, как вероятный.

Это хорошо работает для нас с командой 12. Надеюсь, это помогло. Удачи!

48

У нас есть основной репозиторий, и у каждого разработчика есть вилка этого.

создается ветвь principal/some_project, затем создается одно и то же имя ветви на вилке каждого разработчика, fork / some_project.

(мы используем smartgit, и у нас также есть политика, что пульты называются "principal" и "fork", а не "origin" и "upstream", которые просто путают новых пользователей).

У каждого разработчика также есть локальная ветвь с именем some_project.

в локальная ветвь разработчиков some_project отслеживает удаленный участник ветви / some_project.

разработчики выполняют свою локальную работу над ветвью some_project и push-to в свою вилку/some_project, время от времени они создают запросы на вытягивание, так работа каждого разработчика объединяется в principal/some_project.

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

Это нормально, и все, что нужно сейчас, - это способ объединить текущие обновления, которые появляются в principal/master (например, срочные исправления или другие проекты, которые доставляются до завершения some_project).

чтобы завершить это, мы обозначаем "ветвь", их роль заключается в локальном объединении обновлений из master в some_project с помощью merge (не pull, rebase) в SmartGit. Это тоже может иногда генерировать конфликты и их необходимо урегулировать. Как только это будет сделано, разработчик (ведущий ветвь) принудительно нажимает на свою ветвь fork/some_project, а затем создает запрос на вытягивание для слияния в principal/some_project.

Как только этот запрос на вытягивание объединен, все новые коммиты, которые были на principal/master, теперь присутствуют в ветви principal/some_project (и ничего не было перезагружено).

поэтому в следующий раз каждый разработчик находится на some_project и тянет (напомним, их отслеживается ветвь-principal / some_project), они получат все обновления, которые будут включать материал, объединенный с principal/master.

Это может звучать долго, но на самом деле это довольно просто и надежно (каждый разработчик может также просто слиться локально с principal/master, но это аккуратнее, если один человек делает это, остальная часть команды живет в простом мире, как единый рабочий процесс разработчика).

4

вы можете ознакомиться Git-flow это может помочь вам

http://nvie.com/posts/a-successful-git-branching-model/

3

Я думаю, что до сих пор никто не ответил на исходный вопрос о том, как сотрудничать в тематических ветках, поддержание чистоты истории.

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

лучшее, что вы могли бы сделать в вашем конкретном случае, когда Server dev не заботится об изменениях клиента dev, - это локально fork client ветви от dev / feature и перебазировать эту часть поверх сервера работают непосредственно перед завершением функции -или ослабить ограничения и переключиться на другой рабочий процесс, как вы сделали;)

3

что сделает невозможным для него перебазирование или изменение коммитов, которые уже опубликовано.

Это зависит от вашей аудитории. "Server dev "может подтолкнуть" базовую структуру "к Bitbucket, чтобы" client dev " имел к ней доступ. Да, это действительно потенциально значит, что другие будут иметь доступ к этим "временным" совершает.

однако это будет проблемой, только если другой пользователь разветвлен от одного из этих коммитов до они были перебазированы. На меньшем проекте / меньшем userbase эти временные коммиты могут никогда не быть замечены даже до того, как произойдет ребаз, что отрицает риск.

решение за вами, если риск ветвления от этих временных коммитов слишком велик. Если это так, вам нужно будет, возможно, создать второе частное РЕПО Bitbucket для этих частных изменений. Другой вариант-сделать коммитов слияния вместо перебазирование, но это тоже не идеально.

2

позвольте мне рассказать вам, что мы делаем здесь, когда несколько разработчиков работают над одним проектом (даже иногда работают над одними и теми же контроллерами/моделями/представлениями).

в первую очередь наша команда-Лидер создала git-проект с двумя ветвями

  1. Master (он защищен один, никто не может нажать здесь, кроме team-lead)
  2. развитие (все разработчики могут нажать здесь)

Они сказали нам работать над нашей местной средой и создавать коммиты, когда мы выполнено одно из назначенных заданий.

теперь в вечернее время (или, скажем, время закрытия-уход), мы делаем это:

  1. Git Pull

каждый разработчик, который работает над одним и тем же проектом, тянет текущую ветку разработки на свою локальную (сделайте то же самое утром - при запуске на день).

затем team-lead сказал разработчику зафиксировать все коды и нажать один за другим, а затем один тянуть.

для ex.

  • dev1 создает фиксацию и нажимает на сервер
  • dev2 снова тянет и создает commit и push
  • dev3 снова тянет и создает commit и push
  • и так далее..

теперь проблема в конфликтах:

  • когда-то при вытягивании кода из ветки разработки git уведомляет, что мы автоматически объединили все конфликты - - - это означает, что git автоматически применял новые изменения, сделанные другим разработчиком
  • но когда-то тот же git говорит, что автоматическое слияние не удалось, и показывает некоторые имена
  • затем командная роль входит в картину - что он делает: "он просматривает все перечисленные файлы (во время автоматического слияния неудачного процесса) и объединяет конфликты вручную и создает фиксацию и толчок к серверу.

теперь, как объединить вручную: GIT просто обновляет файлы конфликтов со всем содержимым, как это:

<<< HEAD
New lines from server that you don't have is here shown
=====
Your current changes....
>>> [commit id]

Team-lead обновляет этот файл после анализа :

 New lines from server that you don't have is here shown
 Your current changes

и создает фиксацию и толчок.

снова утром мы тянем (просто чтобы убедиться, что мы ничего не пропустили с предыдущего дня), Вот как мы здесь работаем.

1

правила запомнить:

  • имеем 1 master и 1 develop филиала
  • есть функция ветви икру от develop филиала
  • каждый раз, когда у вас есть версия, готовая к QA чтобы проверить, слиться в develop
  • есть релиз ветви икру от develop филиала
  • сделайте исправления ошибок в ветвях выпуска
  • когда у вас есть версия, готовая к QA для того чтобы испытать, слейте в develop
  • когда у вас есть версия, готовая к производства, сливаются в master, и создать тег для

следующая диаграмма-это стратегия "бычьего глаза", которой следуют команды по всему миру (кредит: взят из здесь):

enter image description here

1