git配置

# 配置用户名和邮箱
git config --global user.name "your name"
git config --global user.email "your email"
# 示例
git config --global user.name "秦腾"
git config --global user.email "qinteng@yuelaidian.com"

master

主分支master用于对外发布版本,任何时候在这个分支获得的软件都是稳定版本

作用：代表线上稳定运行的版本，所有对外发布的版本都基于这个分支进行打包部署。代码处于随时可部署到生产环境的状态，应该保持高度稳定，只包含经过全面测试、修复了所有缺陷并且通过了严格质量审查的代码。
使用原则：不直接在该分支上进行开发工作，而是从其他分支合并代码进来，比如从预发布分支经过测试没问题后最终合并到主分支，合并操作应该谨慎进行，做好充分的测试与验证，确保不会引入新的问题影响线上环境。

develop

开发分支 develop 用于日常开发,存放最新的开发版本

作用：是团队成员日常开发工作的汇总分支，开发新功能、修复缺陷等工作对应的代码都会先提交到这个分支上进行集成和初步测试。它相当于一个测试的环境，里面的代码虽然不断在更新变化，但整体朝着可发布的目标演进。
使用原则：开发人员每天都会频繁地将自己本地开发完成且自测通过的代码分支合并到该分支。开发过程中如果发现分支有冲突等问题，需要及时在这个分支上协调解决，确保代码能正常整合，定期从该分支拉出预发布分支进行进一步的测试和上线准备工作。

feature

功能分支 feature 开发某项特定功能,从master分支上面分出来的,开发完成后,再合并到develop分支

作用：用于开发具体的某个新功能。每当要添加新的功能模块时，从开发分支（develop）上拉出一个独立的功能分支，不同的功能由不同的功能分支承载，这样各个功能的开发相互隔离，不会相互干扰，方便并行开发。例如要开发用户登录功能、商品搜索功能等，都会各自创建对应的功能分支。
使用原则：功能分支的命名通常可以采用规范的格式，比如feature/功能名称，像feature/user-login表示用户登录功能分支。开发人员在自己负责的功能分支上进行代码编写、单元测试等工作，功能开发完成且自测通过后，将其合并回开发分支（develop），合并前需要确保和 develop 分支的代码不存在冲突，如有冲突要先解决冲突再合并。

release

预发布分支 release 发布版本之前从develop分支分出来的一个用于测试的分支;完成测试工作后,再合并到master和develop分支上.

作用：当开发分支（develop）上的代码积累到一定程度，具备了发布的条件时，从 develop 分支拉出发布分支，用于进行发布前最后的测试、修复小的缺陷、调整配置等工作，确保即将发布到生产环境的代码质量。例如准备发布 1.0 版本，就可以拉出release/1.0这样的发布分支。
使用原则：发布分支的命名可以是release/版本号格式。在这个分支上只做一些针对当前版本发布相关的小修改，比如修复在测试阶段发现的关键问题、更新版本号等操作。测试通过后，将发布分支分别合并到主分支（master）用于上线部署，以及合并回开发分支（develop），保证开发分支的代码也更新到最新发布的状态，便于后续继续开发。

hotfix

补丁分支 hotfix 修复已发布软件的bug分支,从master上分支出来,开发完成后,再合并到master和develop分支上;

作用：主要用于紧急修复线上环境出现的问题（即生产环境的 bug）。线上出现问题需要立刻解决时，直接从主分支（master）拉出修复分支，这样能快速定位到线上版本对应的代码状态，在修复分支上完成问题修复并进行必要的测试后，将代码同时合并到主分支（master）以快速部署到线上解决问题，以及合并到开发分支（develop），让开发分支的代码也同步修复该问题，避免后续开发中再出现同样的隐患。
使用原则：命名通常采用hotfix/问题描述这样能清晰体现修复内容的格式，比如hotfix/login-bug表示修复登录相关的紧急问题。修复分支的优先级通常很高，需要尽快完成代码修改、测试以及合并操作，确保线上环境能尽快恢复正常运行。

提交标签

feat（新功能）
fix（修复 bug）
docs（文档更新）
style（代码格式调整）
refactor（代码重构）
test（测试代码）
chore（构建或工具更改）

场景1 项目初始化

创建master分支
创建develop分支

场景2 功能开发

从develop分支上创建feature分支
在feature分支上修改代码(可多次提交)
完成功能开发
将feature分支合并回develop分支(期间在develop分支上可能存在修改)
测试人员测试成功后,删除feature分支

场景3 测试、缺陷修复与版本发布

从develop分支上创建release分支,提交测试
如果测试缺陷需要修复,从release分支上创建hotfix分支进行bug修复;
缺陷修复完成后,将hotfix分支合并到release分支;合并完成后删除hotfix分支;
重复步骤2、3完成所有缺陷修复;
测试通过后,将release分支合并到master分支,发布稳定软件版本,并打tag记录发布软件版本信息;
将release分支合并到develop分支,合并测试中的缺陷修改;
成功将release分支合并到master分支和develop分支后,删除release分支.

场景4 发布产品缺陷修复

从master分支上创建hotfix分支;
在hotfix分支上完成缺陷修复,并测试通过
将hotfix分支合并到master分支;合并完成后删除hotfix分支;发布稳定软件版本;并打tag记录发布软件版本信息;
将hotfix分支合并到develop分支,合并缺陷修改
成功将hotfix分支合并到master分支和develop分支后,删除hotfix分支.

场景5 需求开发上线冲突

需求1开发完成，已合并到develop分支，但未经过测试，需求2需要先测试上线。
回滚需求1：使用 git revert 或 git reset 将需求1的代码从 develop 分支移除。
发布需求2：从 develop 分支创建发布分支，测试并发布需求2。
重新合并需求1：在需求2发布后，重新将需求1合并到 develop 分支，并发布需求1。

develop
   |
   |--- feature/需求1 (已合并)
           |
           |--- git revert (回滚需求1)
   |
   |--- release/需求2 (测试与发布)
           |
           |--- master (v1.0.0)
   |
   |--- feature/需求1 (重新合并)
           |
           |--- release/需求1 (测试与发布)
                   |
                   |--- master (v1.1.0)