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

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

  1. рабочие процессы / модели ветвления

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

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

  3. Я ищу натуральный workflow

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

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

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

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

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

  6. надлежащие процедуры, такие как обзор кода и выпуск было бы, конечно, прекрасно.

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

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

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

4 ответов


самая тревожная функция, которую новые разработчики DVCS должны реализовать, - это публикации:

  • вы можете импортировать (fetch/pull) любой удаленный РЕПО вам нужно
  • вы можете опубликовать (push) в любом (голом) РЕПО, которое вы хотите

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

  • только перебазировать ветку, если она не была нажата (не нажата с последнего rebase)
  • только нажмите на голое РЕПО (обязательно с Git1.7)
  • соблюдать советы Лайнуса по rebase и слияниям

теперь:

рабочие процессы / модели ветвления:

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

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

слияние vs перебазирование (запутанная vs последовательная история):

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

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

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

Как избежать создания конфликтов слияния (из-за cherry-pick)?

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

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

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

как разложить в тематических ветках?

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

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

надлежащие процедуры, такие как обзор кода и выпуск ?

ветви интеграции (в выделенной интеграции) РЕПО может помочь разработчику:

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

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

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

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

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

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

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

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

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

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

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

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


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

"благословенное" РЕПО каждый толкает и тянет в/из, в основном топология клиент-сервер.

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

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

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

чтобы освободить ветвь, она нажимается на благословенное РЕПО, и канбан-карта перемещается в ready for review.

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

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

при нажатии нового тега в благословенное РЕПО появляется новая возможная база для нового особенности.

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


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

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

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

  • исправление/recursive_loop
  • исправление/sql_timeout
  • функция/new_layout
  • функция/enhanced_search