在工作中进行团队协作开发时，我总结出了一套完整的Git分支处理和代码提交流程，适用于从新功能开发到最终合并至生产环境的全周期管理,希望能够对刚参加工作的小伙伴提供一些帮助:

---

1. 创建新功能分支

• 目的：隔离开发新模块，避免影响主分支。
• 操作：

切换到最新的 dev 分支（假设 dev 是开发主分支）
git checkout dev
git pull origin dev

创建新功能分支（例如：feature_new_module）
git checkout -b feature_new_module`在这里插入代码片`

---

2. 开发与提交代码

在功能分支上开发：

• 编写代码、添加新模块。
• 定期提交，描述清晰的 commit 消息：

git add .
git commit -m "feat: 新增用户管理模块"

---

3. 同步主分支最新变更

避免冲突：开发期间，主分支（dev）可能有其他同事的代码更新。

切换回 dev 分支并拉取最新代码
git checkout dev
git pull origin dev

切换回功能分支，合并 dev 的最新变更
git checkout feature_new_module
git merge dev

• 若出现冲突，手动解决后提交：

git add <有冲突的文件>
git commit -m "resolve conflicts"

---

4. 提交代码审查与测试

发起 Pull Request (PR)：

• 将 feature_new_module 提交到 dev 分支，创建 PR。
• 团队成员审查代码，确保逻辑正确、无漏洞。
• 通过自动化测试（如单元测试、集成测试）。

---

5. 合并到测试环境（dev 分支）

合并到 dev：

• 确认 PR 通过审查和测试后，合并到 dev 分支。

# 方式一：GitHub/GitLab 的 Web 界面合并 PR
# 或者本地执行（需确保本地 dev 是最新的）

git checkout dev
git merge feature_new_module

---

6. 部署到测试环境验证

部署测试：

• 将 dev 分支部署到测试环境（如 staging 环境）。
• 验证新模块的功能、性能、兼容性。

---

7. 合并到生产环境（master 分支）

• 准备发布：

• 确认 dev 分支已通过所有测试。

• 从 dev 合并到 master（生产主分支）：

git checkout master
git pull origin master  # 确保本地 master 最新
git merge dev

• 可选：打标签标记版本（如 v1.2.0）：

git tag -a v1.2.0 -m "Release version 1.2.0"
git push origin v1.2.0

---

8. 部署到生产环境

• 部署生产：

• 将 master 分支部署到生产服务器。

• 监控日志，确保新模块运行正常。

---

9. 清理分支（可选）

• 删除旧分支：
  git branch -d feature_new_

module  # 本地删除
git push origin --delete feature_new_mod

ule # 远程删除

---

流程图示

[开发] feature_new_module → [测试] dev → [生产] master
       ↑                  ↑                ↑
      开发               合并+测试        合并+发布

---

10.关键注意事项

1.分支策略：

master 保持稳定，仅用于生产发布。

• dev 作为开发主分支，集成所有已完成的功能。
• 功能分支以 feature_ 命名，基于 dev 创建。

2.代码规范：

使用语义化 commit（如 feat:、fix:）。

• 保持 commit 历史清晰，便于追溯。

3.自动化工具：

• 结合 CI/CD（如 Jenkins、GitHub Actions）实现自动测试和部署。
  如果需要更详细的 Git 命令或特定场景（如热修复）的流程，可以进一步补充说明！

11.常用命令速查表

最后奉上一张命令速查表,不想每次点开图片去看,也可以直接买一张常用命令的鼠标垫,实测非常好用😀😀

---