От ваших вопросов я чувствую, что ваше мышление по-прежнему относится к централизованной системе контроля версий. В распределенной системе сервер уже не «рабочее место», а просто зеркало коллективной работы. Таким образом, это даже не является строго необходимым.
Обычно в центральном репозитории есть только ветка master и теги релиза. Это должно отражать только общий фактор каждого. Ветви в распределенной системе являются очень частными, и поэтому должны оставаться локальными.
В моей работе над своим личным репозиторием у меня есть следующие ветки:
master является точным отражением центральной master. Я никогда не ввязываюсь в это. Вместо этого я только вытягиваю из центрального зеркала в свой master. develop-* - это набор функциональных (рабочих) ветвей, ответвляющихся от ветви release. Например, у меня может быть ветка с именем develop-foo_performance, где я настраиваю производительность класса Foo. Или у меня может быть ветка develop-cosmetics, где я накапливаю небольшие косметические коммиты. В основном это кратковременные ветви для очень специфических задач. Это черновик веток; Я фиксирую здесь все время , свободно пишу сообщения о коммите и не задумываясь о том, «является ли это изменение достойным коммита». Это моя личная, скрывающая ошибки история отслеживания Ctrl-S. release - это ветвь, в которую я помещаю сквош, готовый к публикации. Когда я закончу писать свою конкретную идею для настройки производительности для Foo на ветви develop-foo_performance, я, вероятно, получу набор неорганизованных коммитов, экспериментирующих в разных направлениях. Я перебираю эти коммиты в ветку release, разбивая их на логические коммиты, ориентированные на особенности - часто на один коммит. Этот сквош отбрасывает весь код, который не оказался в конечном состоянии, поэтому история, показанная release, очень чистая и линейная; все эксперименты прошли, как будто я идеальный разработчик, который может заглянуть в будущее, никогда не ошибается и имеет потрясающе описательные коммиты. В конце дня я проталкиваю свою ветку release к центральному зеркалу, а затем достаю пульт master и объединяю его с моим master. napkin - моя ветка личных заметок. Его корневая фиксация отличается от master. Я никогда не сливаю и не переделываю эту ветку в какую-либо другую, никогда не толкаю и не втягиваю в нее, никогда ничего не объединяю здесь. Здесь я храню свой файл задач, найденные ошибки, свои личные заметки, идеи, вопросы для размышлений или любые другие документы, написанные в свободной форме. Это непересекающаяся ветвь, и это для моего личного способа делать вещи: никто никогда не видит это. Это держит меня организованным и ясным.
Для любого моего проекта, будь то на работе или дома, это единственные ветви, которые у меня есть. Я только создаю новые develop-* ветви и удаляю полные и неудачные. Другие ветви никогда не умирают и никогда не перебазируют. Обратите внимание, что когда я объединяю пульт дистанционного управления master с моим master, слияние должно быть ускоренным. Это потому, что я никогда не зацикливаюсь на своем собственном master - только втягиваю в него.
Этот рабочий процесс поддерживает интеграцию разработчика; разработчик, отвечающий за интеграцию работы других людей в центральную ветку master. Если люди никогда не переходят в свою личную ветку master, у них есть гарантия, что их личная master выглядит точно так же, как и в производственной кодовой базе. Это своего рода сеть безопасности, поэтому люди всегда могут отойти от нее, если им нужна чистая база кода.
Если два разработчика хотят поделиться результатами эксперимента, они могут отправлять друг другу запросы на извлечение или отправлять коммиты по электронной почте с git format-patch. Это распределенная работа в ее лучшем виде: общение между сверстниками, и люди, которые не заботятся об эксперименте, не должны его видеть. Они остаются сфокусированными, и проект для них выглядит меньше и проще.