Полноценная модель ветвления Git

Оригинальный личный блог:Полноценная модель ветвления Git

Сегодня я представлю модель ветки Git, которую буду использовать в своей работе.

Сначала вставьте изображение, чтобы выразить уважение, изображение взято из:A successful Git branching model

сплетни

В школе, независимо от того, пишете ли вы дизайн курса самостоятельно или выполняете проекты для учителей, Git используется, когда 2–3 человека совместно работают над разработкой, но они просто используют предоставляемую им функцию совместной работы над кодом. После завершения разработки нет обслуживания после проверки учителем, и проект для учителя также основан на характеристиках проекта: нет постоянства, разовая разработка, поэтому нет модели ветки Git. На предприятии приложение часто имеет длинную жизненную линию и состоит из множества итерационных проектов разработки.В настоящее время для решения проблемы совместной работы над кодом десятков или даже сотен людей требуется полный набор стандартизированного процесса разработки кода.

Я до сих пор помню, что когда я был старшим в школе, я ездил на энтерпрайз на стажировку, тогда в небольшой команде было всего 3 разработчика, не было стандарта использования git, была только одна ветка master , и не было стандарта управления для проекта. В то время часто происходило покрытие кода, различные коды объединялись, и онлайн-код не знал, какой код узла. . . К моменту моего ухода эта модель ветвления не использовалась. После выпуска я присоединился к банку, не говоря уже о модели филиала, Git бесполезен, я не знал о модели филиала, пока в этом году не перешел в интернет-компанию. Таким образом, в вашей работе может не использоваться эта модель филиала.Если она находится в Интернет-предприятии, она, вероятно, будет использоваться.

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

Введение в филиал

master: Код для этой ветки — это код, выпущенный в производство.

develop: код для этой ветки является предварительным выпуском для производственного кода.

release: Код в этой ветке — это код, в котором новая версия выпущена в производство.

feature: Код этой ветки является кодом разработки нового требования

hotfix: Код в этой ветке - это код для срочного исправления багов продакшена

Сценарий

Вот несколько сценариев, с которыми вы можете часто сталкиваться на работе.

Руководитель группы назначает новые требования и договаривается о выходе в сеть на следующей неделе (при условии, что это произойдет 1227-го числа). Если есть, то очень просто, оформить ветку на следующей неделе (feature_app1.1.0_1227) на разработку, если нет, то нужно создать новую ветку, создать новую ветку feature (feature_app1.1.0_1227) из ветки разработки , а затем поставить соответствующий pom.xml. Измените номер версии на 1.1.0-SNAPSHOT, обратите внимание на нейминг, например, здесь я использую feature как префикс, вы также можете установить правило самостоятельно.
После разработки требований feature_app1.1.0_1227 тест сдали.К сожалению, в тесте было n ошибок.На данный момент баги еще исправлены на feature_app1.1.0_1227.
Наконец, за день до релиза тестовый ММ сказал, что n раундов тестирования завершены, проблем нет, вытащите онлайн-версию и проведите еще один регрессионный тест. В настоящее время вам необходимо объединить ветку feature_app1.1.0_1227 с веткой разработки, затем создать новую ветку release_app1.1.0_1227 из ветки разработки, а затем изменить соответствующий номер версии на 1.1.0-RELEASE.
Утром в день релиза тестовый ММ использовал для проверки версию release_app1.1.0_1227 и обнаружил еще одну ошибку. Не паникуйте, если это не производственная ошибка, ее легко исправить. На данный момент вам необходимо исправить ошибку в версии_приложения1.1.0_1227. Помните, что вы не можете изменить ее в версии_приложения1.1.0_1227. Ветка feature_app1.1.0_1227 не действует. Она используется только для просмотра записей отправки кода.
Это было безопасно и безопасно ночью, и релиз был запущен.После релиза внезапно обнаружилась аномалия.После локализации проблемы было обнаружено, что строка кода была написана неправильно.После подтверждения с руководителем группы, я сделал изменения в ветке release_app1.1.0_1227.После переупаковки он был выпущен и проверен в течение определенного периода времени, без проблем. . .
Релиз наконец завершен, не забудьте слить версию release_app1.1.0_1227 в ветки develop и master. Также важно слить код ветки разработки в версию после 1227 (если уже есть версия после 1227). Примечание. Будьте осторожны при слиянии кода на этом этапе. Если чужой код конфликтует, вам нужно найти коллегу этого разработчика, чтобы объединить код вместе. Наконец-то хорошо выспалась. . .
Попрощайтесь со старыми требованиями и введите новые требования, и следующая разработка требований будет следовать описанным выше шагам. . .
На следующий день NullPointerException все время сообщалось в продакшене, и было установлено, что оно было вызвано строкой кода, которая не была пустой.После повторного подтверждения оказалось, что эти данные не были пустыми раньше, но теперь это действительно необходимо поддерживать некоторые данные, которые пусты, и их необходимо срочно восстановить.После подтверждения с руководителем группы я вытащил код ветки hotfix_app1.1.1_1228 из основной ветки, исправил исключение NullPointerException и вышел в сеть после упаковки.После проверки что нет проблем, слейте ветку hotfix_app1.1.1_1228 в ветку develop и master, и поставьте ветку development в версию после 1227.

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

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