Git — самый популярный инструмент управления исходным кодом. Чтобы стандартизировать разработку, сохраните отчеты о представлении кода и структуру ветвей git, чтобы упростить последующее обслуживание, а теперь стандартизируйте операции, связанные с git.
управление филиалом
именование ветвей
основная ветвь
- master — это основная ветвь, а также ветвь, используемая для развертывания рабочей среды для обеспечения стабильности основной ветки.
- Основная ветвь обычно объединяется с ветвями разработки и исправления, и код нельзя изменить напрямую в любое время.
развивать филиал
- develop — это ветка разработки, в которой всегда хранится самый последний завершенный код с исправленными ошибками.
- Когда в целом разработаны новые функции, ветви создаются функции на основе ветви разработки.
функциональная ветвь
- При разработке новых функций создайте ветку функций на основе разработки.
- Именование веток: ветки функций, начинающиеся с feature/, правила именования: feature/user_module, feature/cart_module
выпускная ветвь
- релиз — это ветка перед запуском. На этапе выпуска и тестирования код ветки релиза будет использоваться в качестве эталона для тестирования.
当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。
如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。
当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。
ветвь исправлений
- Именование веток: исправление/ начинается с ремонтной ветки, и ее правила именования аналогичны функциональным веткам.
- Когда в сети возникает срочная проблема, ее необходимо вовремя исправить.Используя основную ветку в качестве базовой линии, создайте ветку исправления.После завершения исправления ее необходимо объединить в основную ветку и ветку разработки.
Общие задачи
Добавить новые функции
(dev)$: git checkout -b feature/xxx # 从dev建立特性分支
(feature/xxx)$: blabla # 开发
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(dev)$: git merge feature/xxx --no-ff # 把特性分支合并到dev
исправить экстренную ошибку
(master)$: git checkout -b hotfix/xxx # 从master建立hotfix分支
(hotfix/xxx)$: blabla # 开发
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到master，并上线到生产环境
(dev)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到dev，同步代码
код тестовой среды
(release)$: git merge dev --no-ff # 把dev分支合并到release，然后在测试环境拉取并测试
Производственная среда онлайн
(master)$: git merge release --no-ff # 把release测试好的代码合并到master，运维人员操作
(master)$: git tag -a v0.1 -m '部署包版本名' #给版本命名，打Tag
спецификация журнала
В совместном проекте разработчикам часто необходимо отправить некоторый код для исправления ошибок или реализации новых функций. И файлы в проекте, какие функции реализовывать, какие проблемы решать будут постепенно уходить в прошлое, и ваще нужно тратить время на чтение кода. Но хорошая спецификация журнала для сообщений фиксации помогает нам, а также отражает, является ли разработчик хорошим сотрудником.
Хорошо написанные сообщения фиксации служат трем важным целям:
- Ускорьте процесс рассмотрения
- Помогите нам написать хорошие журналы релизов
- Пусть будущие сопровождающие поймут, почему были добавлены определенные изменения в коде и функциях.
В настоящее время у сообщества есть множество спецификаций написания сообщений коммитов. Из спецификации Angular это наиболее широко используемый метод записи, который является более разумным и систематическим. Как показано ниже:
Базовый синтаксис сообщений фиксации
Наиболее широко в промышленности используетсяAngular Git Commit Guidelines
Конкретный формат:
<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
- type: тип этого коммита, например, стиль документации по исправлению ошибок и т. д.
- scope: объем этого коммита
- тема: Кратко объясните основную идею этого коммита и подчеркните несколько моментов в исходном тексте 1. Используйте повелительное предложение, это очень знакомое и незнакомое слово, чтобы отправить портал в это повелительное предложение 2. Не используйте заглавные буквы первая буква 3. Знаки препинания в конце ставить не надо
- body: используется то же повелительное предложение. В основной части нам нужно подробно описать эту фиксацию, например, мотивацию для этого изменения. Если требуется разрыв строки, используйте |
- нижний колонтитул: опишите проблему или изменение, связанное с ней, подробности см. в кейсе
Описание категории типа:
- подвиг: добавить новые функции
- исправить: исправить ошибку
- документы: только измененная документация
- стиль: только измененные пробелы, отступы формата и т. д., без изменения логики кода
- рефакторинг: рефакторинг кода без добавления новых функций или исправления ошибок
- perf: добавить код для тестирования производительности
- тест: добавить тестовые случаи
- рутинная работа: изменение процесса сборки или добавление зависимых библиотек, инструментов и т. д.
Требования к формату сообщений фиксации
# 标题行：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的化可以添加一个链接到issue地址或者其它文档