Какие Git ветвящиеся модели работают на вас?

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

  1. Модели рабочих процессов/ветвлений

    Ниже приведены три основных описания этого явления, которые я видел, но они частично противоречат друг другу или не уходят достаточно далеко, чтобы разобраться в последующих проблемах, с которыми мы столкнулись (как описано ниже). Таким образом, наша команда до сих пор по умолчанию не очень велика. Вы делаете что-то лучше?

  2. Слияние и перезагрузка (запутанная и последовательная история)

    Должен ли кто-то pull --rebase или ждать слияния с основной pull --rebase пока ваша задача не будет завершена? Лично я склоняюсь к слиянию, так как это сохраняет визуальную иллюстрацию, на основе которой была запущена и закончена задача, и я даже предпочитаю merge --no-ff для этой цели. Однако у него есть и другие недостатки. Также многие не осознали полезного свойства слияния - что он не является коммутативным (объединение ветки темы в мастер не означает слияние мастера в ветку темы).

  3. Я ищу естественный рабочий процесс

    Иногда случаются ошибки, потому что наши процедуры не фиксируют конкретную ситуацию с простыми правилами. Например, исправление, необходимое для более ранних выпусков, должно, конечно, основываться достаточно вниз по течению, чтобы можно было объединить вверх по течению во все необходимые ветки (достаточно ли использование этих понятий?). Однако бывает, что исправление превращает его в мастера до того, как разработчик осознает, что он должен быть размещен дальше по течению, и если это уже нажато (что еще хуже, слито или что-то на нем), то оставшаяся опция - выбор вишни, связанные с ним опасности. Какие простые правила вы используете? Также в этом включена неловкость одной ветки темы, которая обязательно исключает другие ветки темы (при условии, что они разветвлены от общей базовой линии). Разработчики не хотят заканчивать функцию, чтобы начать еще одно чувство, похожее на код, который они только что писали, больше не существует

  4. Как избежать конфликтов слияния (из-за вишневого выбора)?

    Кажется, что верный способ создать конфликт слияния - это черемуха между ветвями, они никогда не могут быть объединены снова? Будет ли применение одной и той же фиксации в revert (как это сделать?) В любой ветке, возможно, разрешит эту ситуацию? Это одна из причин, по которой я не смею настаивать на основном потоке слияния.

  5. Как разложить на актуальные отрасли?

    Мы понимаем, что было бы здорово собрать готовые интеграционные решения из ветвей тем, но часто работа наших разработчиков не была четко определена (иногда так же просто, как "ковыряться"), и если какой-то код уже перешел в "разное", его нельзя вытащить оттуда снова, согласно вышеизложенному вопросу? Как вы работаете с определением/одобрением/выпуском/выпуском своих веток?

  6. Разумеется, правильные процедуры, такие как просмотр кода и выпуск, будут прекрасными.

    Но мы просто не можем держать вещи распущенными, чтобы справиться с этим - любые предложения? интеграционные отрасли, иллюстрации?

Ниже приведен список связанных вопросов:

Также ознакомьтесь с тем, что Plastic SCM пишет о разработке, ориентированной на задачи, и если Пластик не является вашим выбором, изучите модель ветвления nvie и его поддерживающие сценарии.

ОТВЕТЫ

Ответ 1

Наиболее тревожной особенностью новых разработчиков для DVCS должно быть понимание процесса публикации:

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

Из этого вы можете уважать несколько правил, чтобы упростить ваши вопросы:

Теперь:

Модели рабочих процессов/ветвлений:

каждый рабочий процесс поддерживает процесс управления выпуском и предназначен для каждого проекта.
Что я могу добавить к документообороту, о котором вы говорите: каждый разработчик не должен создавать ветвь функции, а только ветку "current dev", потому что правда заключается в том, что разработчик часто не знает, что именно его/ее отрасль будет производить: один (потому что это оказалось слишком сложной функцией), ни один (потому что не готов к выпуску), еще одна особенность (потому что оригинал был "morphed"),...

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

Слияние и перезагрузка (запутанная и последовательная история):

Мне нравится мой ответ, который вы упоминаете (" Описание рабочего процесса для использования git для внутреннего развития ")

Я ищу естественный рабочий процесс:

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

Как избежать конфликтов слияния (из-за вишневого выбора)?

Как заявил Якуб Нарбски в своем ответе, сбор винограда должен быть зарезервирован для редких ситуаций, когда это необходимо.
Если ваша установка включает в себя много выбора вишни (т.е. "Это не редкость"), то что-то не работает.

Применил бы тот же фиксат в revert (как это сделать?)

git revert должен позаботиться об этом, но это не идеально.

Как разложить на актуальные отрасли?

До тех пор, пока отрасль еще не будет продвигаться повсюду, разработчик должен реорганизовать свою историю совершения (как только он/она, наконец, увидит, что разработка принимает более определенную и стабильную форму):

  • несколько ветвей, если необходимо (один по четкой идентифицированной функции)
  • когерентный набор коммитов внутри одной ветки (см. Trimming Git Checkins)

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

Интеграционные ветки (в специализированной интеграции) репо могут помочь разработчику:

  • rebate его/ее развитие поверх этой ветки удаленной интеграции (pull --rebase)
  • решать локально
  • подтолкнуть разработку к этому репо
  • проверить с интегратором, что не приводит к беспорядку;)

Ответ 2

Я думаю, и, возможно, я ошибаюсь, что одна из вещей, которые непонятны в git, - это ее распределенная природа. Это очень сильно отличается от подрывной деятельности в том, как вы можете работать, хотя вы можете имитировать поведение SVN, если хотите. Проблема в том, что любой рабочий процесс будет делать, что здорово, но и вводит в заблуждение.

Если у меня есть мое понимание развития ядра (я сосредоточусь на этом) правильно, у каждого свой репозиторий git для разработки ядра. Существует один репозиторий, linux-2.6.git, который обслуживает Torvalds, который действует как репозиторий выпуска. Люди клонируются отсюда, если они хотят начать разработку функции против ветки "выпуска".

Другие хранилища выполняют некоторую разработку. Идея состоит в том, чтобы клонировать от linux-2.6, разветвляться столько раз, сколько вам нравится, до такой степени, что у вас есть работающая "новая" функция. Затем, когда это будет готово, вы можете сделать его доступным для кого-то, кого считают доверенным, который вытащит эту ветку из вашего репозитория в свою и объединит ее в мейнстрим. В ядре Linux это происходит на нескольких уровнях (доверенные лейтенанты), пока не достигнет linux-2.6.git, и в этот момент он становится "ядром".

Теперь здесь, где это запутывает. Названия веток не обязательно должны быть согласованными между репозиториями. Поэтому я могу git pull origin master:vanilla-code и получить ветку от мастера origin в ветке в моем репозитории под названием vanilla-code. Предоставляя, что я знаю, что происходит, это действительно не имеет значения - оно распространяется в том смысле, что все репозитории являются одноранговыми друг к другу, а не просто передаются на нескольких компьютерах, таких как SVN.

Итак, имея в виду все это:

  • Я думаю, что каждый программист зависит от того, как они делают свое разветвление. Все, что вам нужно, это центральный репозиторий для управления релизами и т.д. Багажник может быть head. Релизы могут быть тегами или ветвями, а исправления, вероятно, являются ветвями. Фактически, я, вероятно, делал бы выпуски как ветки, чтобы вы могли их исправлять.
  • Я бы слился, а не переустанавливал. Если, например, вы берете репозиторий, клонируете его, переходите и делаете какой-нибудь дев, а затем вытащите из своего origin, вы должны в своем репозитории, возможно, создать другую ветку и объединить последний master в yourbranch, чтобы кто-то еще может потянуть ваши изменения с минимальными усилиями. По моему опыту очень редко нужно по-настоящему переустанавливать.
  • Я думаю, что это способ понять, как работает git и что он может сделать. Это займет некоторое время и много хорошего общения - я только начал понимать, что происходит, когда я начал использовать git с другими разработчиками и даже сейчас, некоторые вещи, о которых я не уверен.
  • Ошибки слияния полезны. Я знаю, я знаю, вы хотите, чтобы все это работало, но факт - это изменения кода, и вам нужно объединить результаты во что-то, что работает. Слияние конфликтов на самом деле просто больше программирования. Я никогда не нашел легкого объяснения, что с ними делать, поэтому вот: обратите внимание на файлы с конфликтами слияния, перейдите и измените их на то, что они должны быть, git add . и затем git commit.
  • Однако это подходит. Как я уже сказал, каждый пользовательский репозиторий git является собственником игр, и имена ветвей не обязательно должны быть одинаковыми. Например, если у вас есть промежуточный репозиторий, вы можете применить схему именования, но вам не нужно для каждого разработчика только в репозитории выпуска.
  • Это этап слияния. Вы только объединяетесь в ветки выпуска и т.д., Когда считаете, что код должен быть проверен/прошел проверку качества.

Надеюсь, это поможет. Я понимаю, что VonC просто опубликовал очень похожее объяснение... Я не могу набирать достаточно быстро!

Измените некоторые дальнейшие мысли о том, как использовать git в коммерческих настройках, поскольку это, по-видимому, относится к OP из комментариев:

  • Репозиторий выпуска, который мы будем называть product.git, доступен нескольким старшим программистам/техническим специалистам, ответственным за фактический уход за самим продуктом. Они аналогичны роли разработчиков в OSS.
  • Эти программисты, возможно, также частично участвуют в разработке новых версий, поэтому они могут также кодировать себя и поддерживать varios-хранилища. Они могут управлять промежуточными хранилищами для действительно новых функций, и у них также могут быть свои собственные репозитории.
  • Ниже приведены программисты, ответственные за разработку отдельных бит. Например, кто-то может нести ответственность за работу пользовательского интерфейса. Поэтому они управляют репозиторией UI.git.
  • Ниже приведены фактические программисты, которые разрабатывают функции как свою полноценную повседневную работу.

Так что же происходит? Ну, каждый тянет в начале каждого дня из "восходящего" источника, то есть в репозиторий релиза (который также, вероятно, будет содержать последний материал из предыдущих дней разработки). Все это делают напрямую. Это пойдет на ветку в их хранилище, вероятно, называется "мастером", или, может быть, если вы меня называете "последней". Затем программист выполнит некоторую работу. Эта работа может быть чем-то, о чем они не уверены, поэтому они создают филиал, выполняют работу. Если это не сработает, они могут удалить ветку и вернуться. Если это произойдет, им придется объединиться в основной филиал, в котором они работают. Мы скажем, что это программист UI, работающий на latest-ui, поэтому он выполняет git checkout latest-ui, а затем git merge abc-ui-mywhizzynewfeature. Затем он рассказывает о своем техническом лидерстве (лидерство в интерфейсе), я выполнил такую ​​задачу, вытащил от меня. Таким образом, вывод интерфейса пользователя git pull user-repo lastest-ui:lastest-ui-suchafeature-abc. Затем пользовательский интерфейс просматривает его на этой ветке и говорит, что это очень хорошо, я объединил его в ui-latest. Затем он может рассказать всем, кто находится ниже него, чтобы оттянуть его от своих ветвей ui-latest или любого другого имени, которое они им дали, и поэтому эта функция исследуется разработчиками. Если команда счастлива, лидерство пользовательского интерфейса может попросить руководство по тестированию вывести его из него и слить изменения. Это распространяется на всех (ниже по течению от изменений), которые тестируют его и отправляют отчеты об ошибках и т.д. Наконец, если функция проходит тестирование и т.д., Один из лучших технических путей может объединить его в текущую рабочую копию программы, после чего все изменения затем распространяются обратно вниз. И так далее.

Это не "традиционный" способ работы и предназначен для "сверстников", а не "иерархических", таких как SVN/CVS. По сути, каждый имеет доступ, но только локально. Это доступ к репозиторию и репозиторий, который вы обозначаете как репозиторий выпуска, который позволяет использовать иерархию.

Ответ 3

Модель, которую я использовал с хорошими результатами, такова:

"Благословенный" репо все подталкивают и тянут к/от, в основном, к клиент-серверной топологии.

Нет ведущей ветки, поэтому разработчик не может нажимать какой-либо код на "mainline".

Все события происходят на ветках темы. Мы именуем имена, чтобы легко определить, кто несет за это ответственность: jn/newFeature или jn/issue-1234

На доске имеется также сопоставление между 1 и 1 между ветвями и картами kanban/scrum.

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

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

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

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

Чтобы избежать конфликтов слияния, разработчики любезно просят обновить (объединить) их невыпущенные ветки до последнего тега релиза.

Ответ 4

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

Когда я работаю над новой функцией или исправлением, я делаю это в ветке. Я также тестирую блок в ветке. Если все работает нормально, только тогда я объединю/переустанавливаю обратно в master.

Я пытаюсь использовать общие соглашения об именах веток, например:

  • багфикс /recursive _loop
  • багфикс /sql _timeout
  • Функция /new _layout
  • функция/расширенный_поиск