Предисловие
GitИмя настолько громкое, что я думаю, что все о нем слышали. Знаменитый сайт однополых знакомств GitHubоснован Gitна платформе, которая размещена как единственный формат библиотеки версий. В этой статье не рассматривается Gitподробно использование , а только представлены Gitспецификации процесса разработки на основе , что требует Gitопределенного понимания.
Краткое описание
GitВ управлении самым важным моментом является управление филиалом. В разработке проекта Gitобычно участвуют следующие отрасли:
- master/main: основная ветка.Код официального выпуска версии компилируется с кодом этой ветки.Она часто устанавливается как защищенная ветка .
- dev/develop: ветка разработки, на основе этой ветки строится среда разработки.
- Feature-*: ветвь для разработки конкретной функции.
- hotfix- /fix- :
bugисправить ветку. - Release-*: используется для тестирования платформ.
Для небольших проектов, когда участников меньше, можно только сохранить masterветку develop.
Это просто управление филиалом обычного проекта, только для справки, а конкретную ситуацию нужно детально разбирать.
Реальная ситуация
Сейчас я разрабатываю проект, код написан мной сам и проходит краткосрочные итерации.
developКод пишется на основе ветки каждый день . После написания функции он отправляется непосредственно в developветку для создания тестовой среды и отправляется на тестирование. Если есть какие-либо проблемы, он напрямую модифицируется и отправляется в ветку develop. Это То есть developкод ветки — это код, используемый в тестовой среде.
В конце итерации developмержите ветку masterи сделайте официальную версию tag.
Процесс развития
developВытащите новую ветку из ветки (feature-*/fix-*).- После завершения разработки отправьте ветку на удаленный склад.
- Создайте мерж-реквест (
merge request,feature-*->develop) и попросите менеджера проекта провести проверку кода и объединить ветку сdevelop. - После прохождения теста
developобъедините ветку сmasterветкой и пометьте ее соответствующимtag, обычно официальным номером версии.
Вышеописанный процесс будет повторяться для каждой версии проекта.
задача решена
В процессе итерации ( 1.1) было обнаружено, что была выпущена последняя официальная версия ( 1.0), и необходимо было выполнить капитальный bugремонт, что было весьма срочно. Однако в текущей developветке изменилось множество 1.1функций версии, и тестирование не завершено, поэтому внести изменения непосредственно на основе текущей developветки невозможно.
К счастью, 1.0когда версия была выпущена раньше, developкод ветки был слит в masterветку, теперь вам нужно только masterвытащить код из ветки, чтобы изменить его, а затем слить измененный контент в ветку masterдля выпуска. Здесь следует отметить, что при developдальнейшей разработке ветки необходимо сначала вытащить masterкод и объединить его.Если есть какой-либо конфликт, измените его, чтобы гарантировать, что не будет конфликтов при developслиянии из ветки в ветку в следующий раз.master
Подведем итог
GitДизайн процесса по-прежнему великолепен. Освоив его, вы сможете легко проводить совместные разработки. Рекомендуется потратить больше времени, чтобы понять его.- Для проектов разных масштабов и сценариев
Gitрабочий процесс может быть изменен и оптимизирован самостоятельно.Конечная цель — удобно, быстро и качественно построить систему проекта.
В этой статье в основном описывается построение рабочего процесса, bugкогда онлайн-чрезвычайную ситуацию необходимо устранить в ходе итеративного процесса, то есть обеспечить, чтобы онлайн-среда всегда использовала код ветки:gitmaster
masterОзнакомьтесь с новой веткой и внесите изменения.- Объедините измененный код в
masterветку, скомпилируйте и опубликуйте и нажмитеtag. - Объедините измененную
masterветку с разрабатываемой в данный моментdevelopветкой для разрешения конфликтов. - нормальный процесс развития.
ссылка
Спецификация управления версиями Git (Git Flow).
Подробные шаги по использованию Git для управления ветвями во время быстрой итерации продукта.