Лучшие практики рабочего процесса Git

Глупый вопрос и относитесь ко мне как к новичку в управлении версиями.

Я новичок в Git (раньше я использовал subversion, но только основы). Я понимаю основы Git и его команды ветвления, у меня возникла воображаемая ситуация, и мне нужен ваш совет.

Предположим, мое программное обеспечение в настоящее время имеет версию 1.2, стабильную и выпущенную.

My Software
       v1.0
       v1.1
       v1.1.1
       v1.2 <- Current, Compilable and Released

Сценарий:

У меня есть два разработчика, Джон и Эрик.

  • Джон отвечает за исправления ошибок, о которых сообщают клиенты.
  • Эрик отвечает за новые функции, экспериментирует с ними и исправляет недочеты.

Сейчас январь.

Джон работает над множеством исправлений ошибок, основанных на выпуске v1.2. Каждый день ему приходится коммитить свой код обратно в репозиторий (GitHub), программа может не компилироваться в зависимости от его статуса.

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

Цель

  1. В любой момент я могу вытащить стабильный компилируемый релиз v1.2.
  2. Февраль, я хочу, чтобы v1.3 была выпущена со всеми исправлениями ошибок Джона, и в зависимости от того, сделает ли Эрик (по крайней мере, основную функцию), выпустить ее.

Каков рабочий процесс с GIT?

Если я правильно понимаю GIT, и Эрик, и Джон должны создать свою собственную ветку, а в феврале они должны объединить то, что работает с мастером?

Спасибо


git tags branch version-control
person Liming    schedule 28.12.2009    source источник
comment
вау, спасибо всем за столько хороших ответов и спасибо Брайану за переформатирование моего поста. Очень ценю ваше понимание этого предмета, а что касается Re-base vs Merging, мне придется прочитать немного больше на эту тему, как предложил Мэтью. В общем, теперь я понял. Очень ценю это еще раз   -  person Liming    schedule 29.12.2009

Ответы (5)


arrow_upward
8
arrow_downward

Я бы создал две ветки интеграции в основном репозитории:

  1. master: ветка интеграции для новых функций (поддерживается Эриком)
  2. 1.2-стабильная: ветка интеграции для исправления ошибок (поддерживается Джоном)

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

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

То же самое относится и к Джону. Если, например, Джону нужно исправить две проблемы (скажем, проблему1 и проблему2), у него должны быть ветки fix-issue1 и fix-issue2. Эти ветки должны начинаться с кончика стабильной ветки 1.2. После исправления одной из проблем, скажем, issue1, Джон может объединить ветку fix-issue1 обратно в 1.2-stable. Если коды в основной ветке и ветке 1.2-stable не сильно расходятся, то, вероятно, для Эрика будет хорошей идеей время от времени объединять ветку 1.2-stable в основную, чтобы включить накопленные исправления в следующий выпуск продукта.

Когда придет время выпуска 1.3, Эрик должен убедиться, что все накопленные исправления в стабильной ветке 1.2 и ветках готовых функций были объединены в главную. Затем он может просто пометить v1.3 и создать новую ветку 1.3-stable.

person kaitanie    schedule 28.12.2009

arrow_upward
3
arrow_downward

Противоположные рекомендации относительно тех, кто поддерживает ветку master из Question Mark и kaitanie — Знак вопроса рекомендует Джону работать над master, а kaitanie рекомендует Эрику работать над master — демонстрируют гибкость рабочего процесса Git.

Что касается того, что Крис Никола рекомендует перебазировать вместо слияния, я бы предостерег вас так же, как и в Pro Git< /em> Скотта Чакона, который доступен для бесплатного чтения в Интернете, и я настоятельно рекомендую , «Не переустанавливайте коммиты, которые вы отправили в общедоступный репозиторий». Поскольку «каждый день [Джон] должен возвращать свой код обратно в репозиторий (GitHub)», я, вероятно, воздержусь от перебазирования, за исключением случаев, когда Джон и Эрик используют его локально.

Я рекомендую вам прочитать раздел "Разветвление рабочих процессов" в Pro Git, в котором описываются долгосрочные ветки и тематические ветки. Возможно, вам также следует ознакомиться с разделом "Распределенные рабочие процессы", в котором описывает централизованный рабочий процесс, рабочий процесс Integration-Manager и рабочий процесс диктатора и лейтенантов.

person Matthew Rankin    schedule 29.12.2009

arrow_upward
2
arrow_downward

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

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

Rebase означает, что вместо слияния ветки с мастером вы фактически вытаскиваете изменения из мастера вниз и помещаете их перед всеми изменениями, которые вы сделали в своей ветке. По сути, он объединяет HEAD с началом изменений вашей ветки. Это создает впечатление, что все изменения, которые вы объединяете, начались после последней версии HEAD.

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

И, наконец, последний совет: делайте коммиты небольшими, специфичными для одной конкретной задачи или действия, чтобы каждый коммит мог быть легко изучен другими и то, что было сделано, было быстро понято. Затем коммиты могут служить для документирования вашего прогресса и действий.

person Chris Nicola    schedule 28.12.2009

arrow_upward
1
arrow_downward

Если я правильно понимаю GIT, и Эрик, и Джон должны создать свою собственную ветку, а в феврале они должны объединить то, что работает с мастером?

да

person Antony Hatchkins    schedule 28.12.2009

arrow_upward
1
arrow_downward

Джон должен работать над мастером, Эрик должен работать над веткой с именем WYSIWYG или какой-либо веткой с соответствующим названием.

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

Если Эрик закончил работу над веткой wysiwyg, объедините и ее, и тогда у вас будет компилируемый релиз. затем вы архивируете/уничтожаете/игнорируете ветку wysiwyg, так как она больше не нужна.

person Question Mark    schedule 28.12.2009