Skip to main content

One post tagged with "团队协作"

View All Tags

· 20 min read
Kyle
Hex

Git 与 AtomGit 实践：团队工作流程的探讨与实践​

本教程适用于所有使用 Git 进行团队协作的开发团队。

在软件开发中，选择合适的工作流对于提高团队效率和代码质量至关重要。本文将首先深入探讨团队工作流的理论基础，然后通过一个完整的项目实践示例，展示如何在 AtomGit 上应用这套工作流。

理论篇：工作流设计​

1、分支策略​

在我们的工作流中，主要维护两个长期分支：

  • master: 生产环境分支，始终保持代码的稳定性和可部署状态。
  • testing: 测试环境分支，用于集成和验证待测试的功能。

分支策略设计考虑​

  1. 为何不使用传统的 master/production 分支？

    • 单一测试环境限制：由于团队只有一个办公网测试环境，直接提测多个 feature 分支可能导致混乱和冲突。
    • 简化分支管理：通过设立 testing 分支作为统一的测试入口，简化了分支流转和管理的复杂度。

  2. 分支权限控制

    • master 分支：仅允许通过合并请求（Merge Request, MR）进行代码合并，确保代码的稳定性和审查的彻底性。
    • testing 分支：允许开发人员直接推送代码，便于快速集成和测试。
    • 临时分支：如 feature 分支或 hotfix 分支，由创建者拥有完全权限，便于独立开发和管理。

2、开发场景与分支流转​

在日常开发中，我们主要面临以下几种情形：

  1. 新功能开发
  2. 线上 BUG 修复
  3. 运营文案修改

每种情形有其特定的分支流转流程，确保开发的有序性和代码的稳定性。

2.1 新功能开发​

完整流程：

  1. 从 master 创建 feature 分支
    • 例如：feature/playlist
  2. 在 feature 分支上进行开发
    • 完成功能开发后进行本地测试
  3. 提交第一个 MR 到 testing 分支
    • 必须进行 Code Review
    • 解决 Review 意见
    • 合并到 testing 环境进行全面测试
  4. 测试过程中发现问题
    • 继续在 feature 分支上修复问题
    • 提交新的 commit 并更新 MR
  5. 测试通过后提交新的 MR 到 master
    • 再次进行 Code Review
    • 确认无误后合并到 master
  6. 合并后操作
    • 打 tag 发布代码
    • 删除 feature 分支，保持分支整洁

2.2 线上 BUG 修复​

根据 BUG 的紧急程度，分为两种修复路径：

  1. 紧急修复流程

    • 从 master 创建 hotfix 分支，例如：hotfix/player-crash
    • 完成修复后直接提交 MR 到 master
    • 经过 Code Review 后紧急合并上线
    • 另外提交 MR 到 testing 分支，同步修复
    • 删除 hotfix 分支，避免分支膨胀

  2. 常规修复流程

    • 从 master 创建 hotfix 分支，例如：hotfix/ui-glitch
    • 完成修复后先提交 MR 到 testing 分支
    • 在 testing 环境中进行测试验证
    • 测试通过后再提交 MR 到 master 分支
    • 合并发布后删除 hotfix 分支

2.3 运营文案修改​

文案修改流程与 BUG 修复类似，但主要侧重于内容的准确性和时效性：

  1. 从 master 创建文案分支
    • 例如：content/welcome-text-update
  2. 在文案分支上进行修改
    • 确保修改前后内容对比清晰
  3. 提交 MR 到 testing 分支
    • 进行文案验证和多轮校对
  4. 验证通过后提交 MR 到 master
    • 经过 Code Review 后合并发布
  5. 合并后操作
    • 删除文案分支，保持分支整洁

3、MR 管理规范​

3.1 MR 提交规范​

  1. 标题格式

    • 功能：[Feature] Add playlist function
    • 修复：[Fix] Resolve player crash
    • 文案：[Content] Update welcome text

  2. 描述要求

    • 功能说明/修复内容：简要描述此次更改的目的和范围。
    • 相关的 Issue 链接：关联对应的任务或问题，便于追踪。
    • 测试用例/测试结果：说明如何测试此次更改，确保功能或修复的有效性。
    • 需要注意的事项：任何需要团队成员了解的特别信息。

  3. Code Review 要点

    • 代码规范性：遵循团队的代码风格和最佳实践。
    • 业务逻辑正确性：确保代码的逻辑符合需求和预期。
    • 性能影响评估：评估此次更改是否对系统性能有负面影响。
    • 测试覆盖情况：确保新增或修改的功能配有充分的测试。

3.2 MR 状态流转​

  1. 待审核

    • MR 提交后处于初始状态。
    • 指定审核人员，添加必要的标签。

  2. 审核中

    • 审核人员开始审查代码，提出修改意见。
    • 开发者根据反馈进行修改，更新 MR。
    • 可能经历多轮反馈和修改，直至满足审核要求。

  3. 待合并

    • 审核通过，等待合并操作。
    • 检查是否存在合并冲突，如有需先解决。

  4. 已合并/已关闭

    • MR 成功合并到目标分支，或因特殊原因关闭。
    • 合并后自动触发相应的发布流程（如有配置 CI/CD）。

4、关键规范与约定​

4.1 分支命名规范​

保持分支命名的一致性和可读性，便于识别和管理。

  1. 功能分支

    • 格式：feature/name-description
    • 示例：feature/playlist-management

  2. 修复分支

    • 格式：hotfix/issue-description
    • 示例：hotfix/player-crash-fix

  3. 文案分支

    • 格式：content/page-description
    • 示例：content/welcome-page-update

4.2 提交信息规范​

采用统一的提交信息格式，便于历史追踪和自动化工具解析。

  1. 格式要求

    <type>(<scope>): <subject>

    <body>

    <footer>

  2. 类型说明

    • feat: 新功能
    • fix: BUG修复
    • docs: 文档更新
    • style: 格式调整（不影响代码逻辑）
    • refactor: 重构（不增加功能或修复BUG）
    • test: 测试相关
    • chore: 构建变动或工具更新

5、常见问题处理​

  1. 多功能并行开发

    • 每个功能使用独立的 feature 分支，避免相互干扰。
    • 通过 testing 分支统一管理测试，确保所有功能在同一测试环境中集成。
    • 按照优先级顺序分别合并到 master，保持发布的有序性。

  2. 测试环境损坏

    • 可从 master 分支重新创建 testing 分支，确保测试环境的可用性。
    • 需要重新合并待测功能，确保所有必要的变更被包含。

  3. 合并冲突处理

    • 以 master 分支为基准解决冲突，确保线上代码的稳定性。
    • 在解决冲突前，与相关团队成员沟通，避免重复和错误修改。
    • 使用 Git 的冲突解决工具，逐步排查并解决冲突。

实践篇：完整示例​

项目背景​

为了更好地理解上述工作流，下面通过一个具体的项目实践示例来展示其应用。

项目名称：MusicApp

项目需求：

  1. 开发新的播放列表功能
  2. 修复播放器中的一个紧急 BUG
  3. 更新欢迎页的文案内容

实践步骤​

1. 新功能开发​

需求：开发一个新的播放列表功能，允许用户创建、编辑和删除播放列表。

步骤详解：

  1. 创建功能分支

    # 切换到 master 分支，确保基于最新代码
    git checkout master
    git pull origin master
    # 创建并切换到 feature 分支
    git checkout -b feature/playlist

    注释：

    • git checkout master：切换到主分支，确保从最新的代码开始。
    • git pull origin master：拉取远程主分支的最新更改，避免分支落后。
    • git checkout -b feature/playlist：创建并切换到新的功能分支，后续所有开发在此分支进行。

  2. 开发功能并提交

    # 添加所有更改到暂存区
    git add .
    # 提交更改，采用规范的提交信息
    git commit -m "feat: add playlist feature"
    # 推送分支到远程仓库
    git push origin feature/playlist

    注释：

    • git add .：将当前目录下所有更改添加到暂存区，准备提交。
    • git commit -m "feat: add playlist feature"：提交更改，并添加清晰的提交信息，描述此次更改的目的。
    • git push origin feature/playlist：将本地的 feature 分支推送到远程仓库，以便团队成员进行 Code Review 和协作。

  3. 提交 MR 到 testing

    • 在 AtomGit 上创建 MR
      • 选择 feature/playlist 分支为源分支，testing 为目标分支。
    • 指定 Code Review 人员
      • 选择负责审查代码的团队成员，确保代码质量。
    • 解决 Review 意见并更新 MR
      • 根据审查意见在 feature 分支上进行修改，重复推送和更新 MR，直至审查通过。

  4. 测试通过后提交 MR 到 master

    • 再次进行 Code Review
      • 在合并到 master 前，进行最后的代码审查，确保无遗漏。
    • 确认无误后合并到 master
      • 通过审查后，将功能分支合并到 master 分支。

  5. 合并后操作

    # 切换回 master 分支
    git checkout master
    # 拉取最新的 master 分支代码
    git pull origin master
    # 合并 feature 分支到 master
    git merge feature/playlist
    # 打 tag 标记发布版本
    git tag -a v1.1.0 -m "Release playlist feature"
    # 推送 master 分支和 tags 到远程仓库
    git push origin master --tags

    # 删除本地 feature 分支
    git branch -d feature/playlist
    # 删除远程 feature 分支
    git push origin --delete feature/playlist

    注释：

    • git checkout master 和 git pull origin master：确保本地 master 分支与远程同步。
    • git merge feature/playlist：将功能分支的更改合并到 master。
    • git tag -a v1.1.0 -m "Release playlist feature"：为此次发布打上版本标签，便于版本管理和回溯。
    • git push origin master --tags：将 master 分支和标签推送到远程仓库。
    • git branch -d feature/playlist 和 git push origin --delete feature/playlist：删除本地和远程的 feature 分支，保持分支整洁。

2. BUG 修复​

需求：修复播放器中的一个紧急 BUG，导致部分用户无法正常播放音频。

步骤详解：

  1. 创建修复分支

    # 切换到 master 分支
    git checkout master
    # 拉取最新的 master 分支代码
    git pull origin master
    # 创建并切换到 hotfix 分支
    git checkout -b hotfix/player-crash

    注释：

    • git checkout master 和 git pull origin master：确保基于最新的稳定代码进行修复。
    • git checkout -b hotfix/player-crash：创建一个 hotfix 分支，专门用于修复紧急 BUG。

  2. 修复 BUG 并提交

    # 添加修复后的代码到暂存区
    git add .
    # 提交修复，采用规范的提交信息
    git commit -m "fix: player crash issue"
    # 推送修复分支到远程仓库
    git push origin hotfix/player-crash

    注释：

    • git add .：将修复后的文件添加到暂存区。
    • git commit -m "fix: player crash issue"：提交修复，明确描述此次更改的目的。
    • git push origin hotfix/player-crash：将修复分支推送到远程仓库，以便进行 MR 和快速上线。

  3. 如非紧急，先提交 MR 到 testing

    • 在 AtomGit 上创建 MR
      • 选择 hotfix/player-crash 分支为源分支，testing 为目标分支。
    • 进行测试验证
      • 在 testing 环境中验证 BUG 是否已修复，确保稳定性。

  4. 测试通过后提交 MR 到 master

    • 进行 Code Review
      • 审查修复代码，确保没有遗漏或引入新问题。
    • 合并发布 MR
      • 通过审查后，将修复合并到 master 分支，并进行发布。

  5. 合并后操作

    # 切换回 master 分支
    git checkout master
    # 拉取最新的 master 分支代码
    git pull origin master
    # 合并 hotfix 分支到 master
    git merge hotfix/player-crash
    # 推送 master 分支到远程仓库
    git push origin master

    # 删除本地 hotfix 分支
    git branch -d hotfix/player-crash
    # 删除远程 hotfix 分支
    git push origin --delete hotfix/player-crash

    注释：

    • git checkout master 和 git pull origin master：确保本地 master 分支与远程同步。
    • git merge hotfix/player-crash：将修复分支的更改合并到 master。
    • git push origin master：将 master 分支的最新更改推送到远程仓库。
    • git branch -d hotfix/player-crash 和 git push origin --delete hotfix/player-crash：删除本地和远程的 hotfix 分支，保持分支整洁。

3. 文案更新​

需求：更新应用内的欢迎页文案，使其更加友好和简洁。

步骤详解：

  1. 创建文案分支

    # 切换到 master 分支
    git checkout master
    # 拉取最新的 master 分支代码
    git pull origin master
    # 创建并切换到文案分支
    git checkout -b content/welcome-text-update

    注释：

    • git checkout master 和 git pull origin master：确保基于最新的稳定代码进行文案更新。
    • git checkout -b content/welcome-text-update：创建一个内容更新分支，专门用于文案修改。

  2. 更新文案并提交

    # 编辑 welcome.md 或相应的文案文件
    # 添加修改后的文件到暂存区
    git add welcome.md
    # 提交更改，采用规范的提交信息
    git commit -m "content: update welcome message"
    # 推送文案分支到远程仓库
    git push origin content/welcome-text-update

    注释：

    • 编辑相关文案文件，确保内容准确且符合需求。
    • git add welcome.md：将修改后的文案文件添加到暂存区。
    • git commit -m "content: update welcome message"：提交更改，描述此次文案更新的目的。
    • git push origin content/welcome-text-update：将文案分支推送到远程仓库，以便进行 MR 和文案验证。

  3. 提交 MR 到 testing

    • 在 AtomGit 上创建 MR
      • 选择 content/welcome-text-update 分支为源分支，testing 为目标分支。
    • 进行文案验证
      • 由运营团队或相关人员进行文案审核，确保内容的准确性和合适性。

  4. 验证通过后提交 MR 到 master

    • 进行 Code Review
      • 审查文案更新，确保没有语法或内容上的错误。
    • 合并发布
      • 通过审核后，将文案分支合并到 master 分支，并进行发布。

  5. 合并后操作

    # 切换回 master 分支
    git checkout master
    # 拉取最新的 master 分支代码
    git pull origin master
    # 合并文案分支到 master
    git merge content/welcome-text-update
    # 推送 master 分支到远程仓库
    git push origin master

    # 删除本地文案分支
    git branch -d content/welcome-text-update
    # 删除远程文案分支
    git push origin --delete content/welcome-text-update

    注释：

    • git checkout master 和 git pull origin master：确保本地 master 分支与远程同步。
    • git merge content/welcome-text-update：将文案分支的更改合并到 master。
    • git push origin master：将 master 分支的最新更改推送到远程仓库。
    • git branch -d content/welcome-text-update 和 git push origin --delete content/welcome-text-update：删除本地和远程的文案分支，保持分支整洁。

效果验证​

通过这套工作流，我们实现了以下目标：

  • 功能开发的独立性：每个功能在独立的分支上开发，避免互相影响。
  • BUG 修复的及时性：紧急 BUG 能够迅速修复并上线，保持产品稳定。
  • 文案更新的规范性：所有文案修改经过严格的审核和验证，确保内容质量。
  • 分支管理的清晰性：通过明确的分支命名和管理策略，团队成员能够快速理解和操作。

推荐阅读​

  1. Git 与 AtomGit 实践：从零到一

    • 适合 Git 初学者的入门指南。

  2. Git 与 AtomGit 实践：贡献协作

    • 详细介绍团队协作的最佳实践。

  3. Git 与 AtomGit 实践：项目维护

    • 详细介绍代码审查和合并的最佳实践。

通过这套工作流程，团队可以更高效地进行协作开发。希望本文对你有所帮助！