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

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

У нас есть репозиторий в Bitbucket. Мастер считается, что он содержит только стабильный код. Каждый разработчик должен создать свою ветку и реализовать функции/исправления в своей ветке . Как только он решает, что его код готов, он создает приятную историю ветвей (используя переустановку, изменение, вишневый подбор и т.д.) И толкает ее в битбакет, где создает запрос на растяжение для овладения веткой. QA проверяет функциональность и одобряет (или не одобряет) ее, затем я проверяю код, и если все в порядке, я объединять его работу с мастером (путем быстрой перемотки вперед или переустановки для лучшей фиксации истории).

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

Вы можете увидеть Git -flow, это может помочь вам

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Мастер (он защищен, никто не может толкать здесь, кроме лидера команды)
Разработка (все разработчики могут нажать здесь)

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

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

Git Pull

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

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

Например

dev1 создает коммит и отправляет на сервер
dev2 снова тянет и создает коммит и пуш
dev3 снова тянет и создает коммит и пуш
и так далее..

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

Иногда при извлечении кода из ветки разработки git уведомляет, что мы объединили все конфликты автоматически - это означает, что git автоматически применяет новые изменения, сделанные другим разработчиком.
Но иногда ЖЕ ГИТ сообщает, что автоматическое слияние не удалось, и показывает некоторые имена файлов
затем роль лидера команды вступает в картину - что он делает: "Он просматривает все перечисленные файлы (во время автоматического сбоя процесса слияния) и объединяет конфликты вручную, создает коммит и передает на сервер.

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

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

Руководитель группы обновляет этот файл после анализа:

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

и создает коммит и пуш.

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

Ответ 7

Правила, которые нужно запомнить:

1 master и 1 ветка develop
Есть функция ветвей, созданных в ветке develop
Каждый раз, когда у вас есть версия готова для QA, чтобы проверить, сливаются в develop
Иметь ветки релиза в ветке develop
Сделать исправления в ветки релиза
Если у вас есть версия готова для QA, чтобы проверить, сливаются в develop
Когда у вас будет готова версия для ПРОИЗВОДСТВА, объединитесь с master и создайте для нее тег.

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

Ответ 8

Для точного вопроса, когда несколько разработчиков выполняют одну и ту же задачу, краткий ответ - задача выполнена в ветки интеграции для этой задачи. Эта ветвь 'task' обрабатывается так же, как ветки "master" или "dev" в обычных рабочих процессах Git (как и здесь приводится большинство ответов). Эта ветка интеграции обрабатывается в "Рабочем процессе ветки Git Feature", разработанном в другом месте.

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

пример

Для разработки нового заставки ведущий разработчик (или кто-то другой) делает

git co master
git co -b feature-splash
git push origin feature-splash

Каждый разработчик, работающий над этой функцией:

git co master
git pull
git co feature-splash
git co -b my-feature-splash  // they can name their branch whatever

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

Когда функция завершена, всплеск функции объединяется в мастер. Конечно, этот всплеск функций должен постоянно обновляться с новым кодом на master. Может ли функция-всплеск использовать ребазинг на мастере?

Это не моя оригинальная идея. Я читал об этом в разных местах.