“掌握高效团队协作的秘诀：企业项目中的Git规范实践指南“

---

theme: smartblue

前言

在当今快速发展的软件行业中，团队协作和项目管理变得越来越重要。而作为一种分布式版本控制系统，Git已经成为了开发者们的必备工具。在企业项目中，如何有效地运用Git来提升团队协作效率和项目管理水平呢？本文将为您揭示高效团队协作的秘诀，详细介绍企业项目中的Git规范实践指南，助您轻松掌握项目管理的诀窍。无论您是企业管理者、项目负责人还是开发者，都可以从本文中受益匪浅。让我们一起探索如何运用Git规范来提升企业项目的管理水平，实现高效团队协作。

分支管理

为保证分支的结构清晰和功能明确，请在对分支进行管理时按以下方案执行，并注意以下几点：

• 分支应严格按照命名规范命名，避免选择分支时过于混乱
• 任何非常驻分支应当在合并完成后删除，避免同时存在的分支过多

主分支（master）

命名规范：master

• 主分支即为项目初次提交时的默认分支
• 任何时候不应该直接在该分支上进行开发，同时分支被保护无法进行 push 操作
• 一般情况下生产环境的代码版本应该与该分支上的代码版本保持一致
• 在进行发布时从该分支拉取代码进行发布
• 发布完成后应该在该本分支的当前位置打 Tag，以版本号命名（版本号的制定规则由 Git 项目的负责人决定）

功能分支（feature/*）

命名规范：feature/*（* 部分可任意命名，单词全部小写，单词间使用 - 分隔）

• 功能分支是从主分支动态拉取的，用于开发功能（如产品需求、体验优化、技术优化等）
• 进行任何功能开发都应该拉取功能分支，禁止直接在主分支上做修改
• 功能开发期间随时可以从主分支合并代码到该分支，以保证功能代码不与主干代码冲突
• 功能开发完成提测前必须从主分支合并代码到该分支，以保证提测的代码包括了已上线的主干代码
• 测试期间如果主干代码有大的变动，必须从主分支合并代码到该分支并要求测试验证相关逻辑，以保证功能代码不与主干代码冲突
• 测试完成准备发布时，应先从主分支合并代码到该分支，再发起 MR 将该分支合并回主分支，然后删除该分支，最后使用主分支进行发布
• 在不确定要发布时请勿将分支合并到主分支，避免对代码分离造成困难

Hotfix 分支（hotfix/*）

命名规范：hotfix/*（* 部分可任意命名，单词全部小写，单词间使用 - 分隔）

• Hotfix 分支是从主分支动态拉取的，用于进行现网 Bug 修复
• 修复任何现网 Bug 都应该拉取 Hotfix 分支，禁止直接在主分支上做修改
• Bug 修复完成准备发布时，应先从主分支合并代码到该分支，再发起 MR 将该分支合并回主分支，然后删除该分支，最后使用主分支进行发布
• 在不确定要发布时请勿将分支合并到主分支，避免对代码分离造成困难

注意事项

• 分支命名应该严格按照分支命名规则，禁止使用如 rtxname/featureName 之类不规范的命名

  原因：

  • 如 feature/ 之类的前缀有助于对分支进行分类，防止混淆
  • 分支名不应该包括作者的用户名，因为分支不是按用户进行划分而是按用途和对应功能进行划分的
  • 如果想要查看分支的提交者或提交日期，查看分支的最后提交记录即可
  • 在严格按本指引进行 Git 管理的情况下，不会出现大量闲置分支需要找人认领的情况
  • 分支名单词全小写并使用-分隔是业界目前最普遍的做法，统一命名可以让分支名更清晰易懂

• 当需要修改 master 分支上代码时，应该拉分支修改后通过 merge request（MR）合并，禁止直接在 master 分支修改 push 代码

  原因：

  • 直接在 master 分支上修改代码很多时候是通过复制粘贴代码进行合并，这种操作是严格禁止的
  • 部分在 master 分支上修改代码的行为是为了优化或修复bug，这种情况下应该单独拉取 feature/* 或 hotfix/* 分支修改，之后再通过MR合并回 master 分支

• 合并分支应该使用 git merge 指令或带有 GUI 界面的 Git 管理工具进行操作，严禁通过复制粘贴的方式合并分支代码

  原因：

  • Git 在执行合并操作时并不是简单的文件合并，其背后还有关于合并来源记录，具体可参考 Git 的实现原理
  • 通过复制粘贴方式合并代码只是单纯覆盖了文件，而关于合并来源的记录是缺失的，可能会导致后续代码被覆盖等严重的不良后果
  • 当合并遇到冲突时，应找到冲突点手动解决冲突后提交，禁止在未分析清楚冲突原因的情况下贸然复制粘贴覆盖代码直接提交

• 分支合并入其他分支完成使命后应该立即删除，禁止长时间保留

  原因：

  • 如果分支长时间不删除会导致堆积大量无用分支，导致查找和切换分支困难
  • 分支在使用完后如果不立即删除，之后再找到分支的提交者进行删除会浪费人力成本，所以在 MR 完成后应直接使用 MR 自带的功能第一时间删除源分支
  • 分支被删除并不意味着提交记录会丢失，相反如果分支已被合并，随时可以找到最后提交的节点重新建立分支

• 同目录下文件的文件名应该严格不同，禁止使用仅大小写不同的文件名（如：AAA.txt, aaa.txt）

  原因：

  • Windows下文件名大小写不敏感，仅大小写不同的文件名在Windows下会被识别为同一个文件，导致文件和索引不同步引起混乱
  • 仅大小写不同的文件名在交流时也容易造成误解，应当避免

• 原则上禁止在 Git 中存储任何敏感信息（诸如服务器密码、数据库密码、敏感数据等），如果有特殊情况需要存储应谨慎评估风险

  原因：

  • 一旦文件被提交在 Git 上，由于版本管理的特性，不易删除记录
  • 有很多 Git 项目是在公司内部公开的，如不慎提交，会被外部人员轻易获得
  • 如果一定要使用 Git 作为存储介质，应严格控制项目的读取权限

• 慎用 git rebase 和 git push -f 等指令，除非你很清楚你为什么要这样做

  原因：

  • git rebase 和 git push -f 等指令会导致远端仓库已提交的的记录被修改，如果有其他人正在基于这些修改进行其他修改会造成混乱
  • 如果你很清楚你为什么要使用这些指令，可以在适当的范围使用这些指令

具体场景

为方便大家能快速了解Git的使用方式，列出了一些具体场景的操作流程，供参考：

第一次参与某Git项目开发

1. 如果没有安装过 Git 的话，安装 Git

   • Windows 用户可以选择安装 Git for Windows、GitHub Desktop 或 TortoiseGit
   • macOS 用户直接执行 git 命令会提示安装 Xcode Command Line Tools，安装后即可使用
   • Linux 用户使用系统对应的包管理工具安装 git 即可

2. 如果是首次使用 Git，在 .gitconfig 文件中配置用户信息和编辑器信息

3. 从 Git 平台上克隆项目的 Git 仓库（git clone http://git.code.oa.com/CloudBusinessManage/项目名.git）

4. 进入项目目录开始开发工作

开始开发新需求

1. 进入项目目录
2. 切换到主分支（git checkout master）
3. 从远端拉取最新代码更新本地的主分支（git pull）
4. 从主分支拉出功能分支并切换到该分支（git checkout -b feature/功能分支名）
5. 对文件进行修改，注意新增的文件要添加到 Git（git add 文件名 或 git add *）才会被 Git 追踪
6. 提交修改，附上对提交内容的说明（git commit -m "提交信息"）
7. 推送本地的更新到远端，第一次推送需要指定在远端对应的分支名（ git push -u origin feature/功能分支名），之后直接推送即可（git push）

需求提测

1. 进入项目目录
2. 切换到功能分支（git checkout feature/功能分支名）
3. 从远端拉取最新代码更新本地的功能分支（git pull）
4. 将远端的主分支合并进本地的功能分支（git merge origin/master）
5. 如果合并中遇到冲突，则需要手动解决冲突并在解决完冲突后将文件添加到 Git（git add 文件名 或 git add *），全部解决完成后不带提交信息提交（git commit）
6. 推送本地的更新到远端（git push）
7. 使用功能分支部署环境并提交测试

需求版本发布

1. 进入项目目录
2. 切换到功能分支（git checkout feature/功能分支名）
3. 从远端拉取最新代码更新本地的功能分支（git pull）
4. 将远端的主分支合并进本地的功能分支（git merge origin/master）
5. 如果合并中遇到冲突，则需要手动解决冲突并在解决完冲突后将文件添加到 Git（git add 文件名 或 git add *），全部解决完成后不带提交信息提交（git commit）
6. 推送本地的更新到远端（git push）
7. 在 Git 平台上发起 Merge Request，从功能分支合并到主分支
8. 进行 Code Review 后合并 Merge Request，同时删除源分支（即功能分支）
9. 使用主分支进行发布

FAQ

Q： 业界流行的 Gitflow 工作流是什么？我们为什么不使用 Gitflow 工作流？

A：Gitflow工作流 是一套业界使用较多的 Git 使用规则。虽然 Gitflow 工作流功能强大，但它相对更适合比较固定的版本发布节奏，即严格按照大版本号和小版本号进行迭代并定期发布的方式。而现在的发布节奏更接近按需求发布而非按版本发布，这种情况下作为 Gitflow 工作流中重要一环的发布流程显得较为冗余，因此本指引选择了更为简洁的工作流作为基础。随着项目的发展，项目发布节奏也有可能会发生变化，届时如果有必要也会对现有的规则作出调整。

Q： 我之前使用过 SVN，Git 相比 SVN 在使用上有哪些不同？

A：Git 是新一代的版本管理工具，相比 SVN 更轻量，适合快速迭代快速交付的场景，其主要不同点有以下方面：

• Git 在用户不可见的地方存储项目的多个版本状态；而 SVN 使用 trunk、branch 等目录结构来存储不同分支的代码
• Git 在任何时候工作区内都只存在一个版本的代码，在切换分支时会在同一个目录中切换不同版本的文件；而 SVN 不同分支的代码在不同目录下
• Git 拉取分支成本低（只需创建一个指针）；而 SVN 拉取分支成本高（需要复制整个项目的文件）
• Git 撤销合并操作困难；而 SVN 撤销合并操作相对容易（通过 Reverse Merge 即可实现）
• Git 在本地和远端有两个不同的仓库，可以只使用本地的仓库，也可以通过映射来与远端仓库进行同步；而 SVN 本地和远端是必须保持同步的同一个仓库
• （其他不同点待补充…）

Q： 为什么在实际文件差异很小的时候，在网页上比较分支差异会这么大？

A：（待补充…）