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

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

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

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

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

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

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

Надеюсь, это поможет. Я понимаю, что 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. По сути, у всех есть доступ к фиксации, но только локально. Это доступ к репозиторию и репозиторию, который вы назначаете как репозиторий выпуска, который позволяет вам использовать иерархию.