Причины не работают на мастер ветке в Git

Question

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

Я достаточно счастлив, чтобы работать с ветками, но мне было интересно, почему не работает основная ветка?

Answer 1

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

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

Answer 2

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

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

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

• master
• следующий
• pu
• maint

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

Не уверен, что мое понимание верно, я новичок в git.

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

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

Если каждая функция находится в отдельной ветке, тогда эта задача проста: вы берете старую версию мастера (без A и без B).Вы объединяете ветку B. Готово.