Причины не работать с ведущей ветвью в Git

Итак, я довольно новичок в git, и за последние пару недель я немного читал. Я читал несколько человек, говорящих, что главная ветвь не должна меняться, а разветвляться из и затем сливается с.

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

Ответ 1

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

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

возьмем git.git(официальный репозиторий git) в качестве примера. есть несколько ветвей, наиболее примечательных:

поэтому master содержит код, который, скорее всего, попадет в следующую версию git. next содержит проверенный код, который потенциально может быть объединен с ветвью master. pu (предлагаемые обновления, iirc) содержит совершенно новый (и, возможно,) непроверенный код.

pu считается неустойчивым и будет reset и переустановлен на junio. next может получить reset после выпуска или во время цикла выпуска, но это реже. master установлен в камне и никогда не менялся после того, как он был нажат и стал общедоступным.

вы увидите, что изменения будут объединены от pu до next и от next до master, если они считаются достойными и не сломают материал.

ветвь maint используется для создания исправлений, которые также должны применяться к более старым версиям git. maint обычно объединяется в next и/или master.

вы можете проверить ветки на http://git.kernel.org/?p=git/git.git;a=summary

Ответ 2

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

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

Ответ 3

Единственное, что вам нужно учитывать при использовании DVCS (Distributed Version Control System), например, Git или Mercurial, - это рабочий процесс публикации (ортогональный ветвящемуся рабочему процессу).

Когда у вас есть только ветки, вы спросите себя, какие усилия развития они представляют.
Если master предназначен для представления стабильного кода, например knittl в его ответе, тогда да, вам нужно отделить от /merge до master.

Но когда вы можете клонировать/нажимать/тянуть (то есть публиковать в разных репозиториях, которые могут иметь разные цели сами по себе), тогда "master" может играть другую роль от репо к репо.

  • репо для разработки может иметь много ветвей, причем master обычно представляет наиболее стабильный код.
  • Репозиционирование развертывания может иметь только master, а некоторые ветки поддержки исправлений для срочных исправлений.
  • локальное тестовое репо может иметь только одну ветвь master, переписанную с push для push, чтобы выполнить некоторый код статического анализа с помощью крючка, который контролирует только указанную ветвь master для этого тестового репо.
  • ...

Ответ 4

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

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