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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создается ветвь принципал/некоторый_проект, затем создается ветка с тем же именем для каждой ветки разработчиков, вилка/некоторый_проект.

(Мы используем smartgit, и у нас также есть политика, согласно которой удаленные устройства называются «основной» и «форк», а не «происхождение» и «восходящий», что просто сбивает с толку новых пользователей).

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

Локальная ветвь разработчиков some_project отслеживает удаленную ветку принципал/some_project.

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

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

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

Для этого мы назначаем «руководителя ветки», его роль заключается в локальном слиянии обновлений из master в some_project с использованием слияния (а не извлечения, перебазирования) в SmartGit. Это также может иногда вызывать конфликты, и они должны быть разрешены. Как только это будет сделано, разработчик (руководитель ветки) принудительно отправляет в свою ветку fork/some_project, а затем создает запрос на слияние для слияния с веткой принципал/some_project.

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

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

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

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

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

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

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

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

• Иметь 1 master и 1 develop ветвь
• Ветки функций появляются из ветки develop
• Каждый раз, когда у вас есть версия, готовая для QA тестирования, объединяйте ее в develop.
• Ветки релиза появляются из ветки develop
• Внесите исправления в ветки релизов
• Когда у вас будет готовая версия для QA тестирования, объедините ее в develop
• Когда у вас будет готовая версия для PRODUCTION, объедините ее с master и создайте для нее тег.

На следующей диаграмме показана стратегия «бычьего глаза», которой следуют команды по всему миру >здесь):

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

Первым делом наш тимлид создал git-проект с двумя ветками

1. Мастер (защищенный, сюда никто не может пушить, кроме тимлида)
2. Разработка (все разработчики могут нажать сюда)

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

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

1. Git Pull

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

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

Например

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

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

• Иногда при извлечении кода из ветки разработки git уведомляет, что мы автоматически объединили все конфликты --- это означает, что 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

и создает commit и push.

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

На точный вопрос, несколько разработчиков над одной и той же задачей, краткий ответ: задача выполняется в ветке интеграции для этой задачи. Эта ветка «задача» обрабатывается так же, как ветки «мастер» или «разработчик» в обычных рабочих процессах Git (как и в большинстве приведенных здесь ответов). Эта ветка интеграции обрабатывается в «рабочем процессе ветки функций Git», разработанном в другом месте.

В этой ветке задачи разработчики, работающие над этой задачей, совместно используют код, используя обычные команды 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. Точно так же, как это делается для священной ветки «мастер».

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

Это не моя первоначальная идея. Я читал об этом в разных местах. Обратите внимание, что во многих статьях о рабочих процессах эта конкретная ветвь задачи на самом деле не является концепцией. Например, в одной статье у нас есть «Ветви функций обычно существуют только в репозиториях разработчиков, а не в источнике». Возможно, задача, для которой требуется более одного разработчика, всегда разбивается на подзадачи? Я думаю, если вы знаете будущее и знаете, что требуется.

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

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