团队开发中的 Git 工作流程

最近在实习，接触到了企业内部开发时的 Git 工作流程。刚开始使用有点陌生，慢慢就熟悉了。虽然 Git 的命令和选项数量不少，但是在工作中用到的命令和操作其实不多。所以在这里进行总结，方便自己用到的时候找，并且相信对 Git 小白会有所帮助。

Git 原理

Git 是一个版本控制系统，它通过记录每次文件的快照而非差异，来管理代码的版本历史。它允许开发者在本地创建多个并行的分支进行独立开发，并能安全地合并这些分支。Git 使用 SHA-1 哈希值来确保数据的完整性，防止任何篡改。其设计使所有操作（如commit、log、merge等）都可以在本地完成，从而提高了效率和速度，同时还支持通过远程仓库进行团队协作和代码共享。

Git 的发展历史悠久，介绍它原理的资料非常齐全，在这里就不赘述了。简单了解 Git 的原理，能帮助我们更好地学习如何使用它。感兴趣的可以看这里 MIT 对 Git 的介绍。

分支分类

大厂使用的分支主要是四种：dev（开发）、test（测试）、uat（预发）、release（生产）。

小厂一般一个dev（开发）、一个master（生产）就够了，测试都是开发来做😄。

除此之外，还有下面这些分支。这些分支经过 pr、review，然后 merge 到 dev 分支。
这些分支推荐的命名格式是：分支责任/名称。例如：feature/support-feign。不同的公司会有不同的规范。

--  feature :    新功能
--  fix :        修复 bug
--  hotfix :     修复紧急 bug

在开发过程中的每次 commit、pr 和 merge 都可以通过 CI 脚本，记录到项目管理工具 youtrack 对应的 task 上，有助于项目的维护和审查。如果没有使用过 YouTrack 的同学可以忽略这段话。

开发流程

大厂的开发流程如下：

1. 需求评审
2. 开发排期
3. 编码开发
4. 冒烟测试（自检）
5. 冒烟通过，提交测试，合并代码到测试分支，部署测试环境
6. 测试环境测试，开发修 bug
7. 测试完成，提交预发，合并代码到预发分支，部署预发环境
8. 预发环境测试，开发修 bug（修完的 bug 要重新走测试再走预发）
9. 测试完成，产品验收
10. 验收完成，提交生产，合并代码到生产分支，部署生产环境
11. 生产运营（客户）验收
12. 验收完成，结项

小厂一般 3-8 步骤都是开发去做，并且流程会做相应的简化。例如冒烟测试通过后就进行验收，然后部署生产环境。

Git 工作流程

上面的图片是 Git 的工作流程，主要包括下面七个步骤：

1. 在 Github 上 fork upstream 原仓库到自己的账户上，即 origin 远程仓库。
2. 从自己的账户上 git clone 项目到本地，即本地仓库。
3. 从 upstream 原仓库上 git pull 最新代码到本地仓库，即最新的本地仓库。（1和2只需要操作一次，每次写代码前都要进行3这步）
4. 在本地编写代码后，git commit 和 git push 代码到自己账户的 origin 远程仓库上。
5. 在自己的账户上进行 pull request。
6. 一般是同事进行代码的 review，看代码是否有问题。
7. 最后 merge 到 upstream 的主分支上，开发的话一般是 dev 分支。

下面对每个步骤进行详细的解释。

1. fork 仓库

GitHub 上的项目都有一个 Fork 按钮，我们需要先将开源项目 fork 到自己的账号下，如下图所示：

然后返回到自己的账号，就能找到 fork 的项目了。这个项目在你自己的账号下，也就意味着你有任意修改的权限了。我们后面要做的事情，就是将代码变更提到自己 fork 出来的代码库里，然后再通过 Pull Request 的方式将 commits 合入上游项目。

2. clone 到本地

将自己账号下 fork 的项目 clone 到本地，例如下面命令：

// 克隆项目
git clone https://github.com/test/Java-Backend-Demo.git
// 进入项目目录
cd Java-Backend-Demo
// 设置 upstream 项目地址
git remote add upstream https://github.com/rongliangtang/Java-Backend-Demo.git
// 禁止从本地推送变更到 upstream
git remote set-url --push upstream no_push

通过执行 git remote -v ，我们在本地看到的 remote 信息应该是这样的：

origin  https://github.com/test/Java-Backend-Demo.git (fetch)
origin  https://github.com/test/Java-Backend-Demo.git (push)
upstream  https://github.com/rongliangtang/Java-Backend-Demo.git (fetch)
upstream  no_push (push)

我们的本地的代码变更永远只提交到 origin，然后通过 origin 提交 Pull Request 到 upstream。

3. 更新本地仓库

上述1、2两步一般只需要执行一次，之后每次我们在本地写代码前，都需要更新本地仓库，确保本地分支的代码是最新的。

// 切换到 dev 分支
git checkout dev
// 获取 upstream 所有分支的最新提交
git fetch upstream
// 基于当前所在的分支 dev 创建新分支 feature/xxx，并切换到这个分支 
git checkout -b feature/xxx

注意，使用 git fetch 时，本地应该没有 commit ，否则应该使用 git pull --rebase upstream dev 。它的作用是获取 upstream dev 分支的最新更新，并将当前分支的提交重新应用到这些更新之上。

4. commit + push

在本地写完代码后，可以通过下述命令将变更上传到自己账户下的 origin 远程仓库。

git add <file>
git commit -s -m "some description here"

注意 commit 的规范要满足部门的要求。

// 获取 upstream dev 分支的最新更新，并将当前分支的提交重新应用到这些更新之上。
git pull --rebase upstream dev
git push origin feat-xxx --force

注意 push 前，需要 pull 一下，获取 upstream dev 分支的最新更新，并将当前分支的提交重新应用到这些更新之上。如果有冲突可以在 IDE 中查看并解决冲突。最后再 push 代码到 origin 远程仓库。

这里大家需要理解这几个命令和参数的含义，灵活调整。比如你也可以用git add --all完成 add 步骤，在 push 的时候也可以加--force参数，用来强制覆盖远程分支（假如已经存在，但是 commits 记录不合你意）。但是记得git commit的-s参数一定要加。

也可以通过 IDE 来 commit 和 push，记得 push 前需要在命令行 pull 一下，如下图所示。

5. 发起 Pull Request

在完成 push 操作后，我们打开 GitHub，可以看到一个黄色的提示框，告诉我们可以开一个 Pull Request 了。

点击 Compare & pull request，创建 pr，选择对应的分支，填写信息。

注意 pr 的规范要满足部门的要求。

6. Review 代码

pr 提交后，一般同事会 review 我们提交的 pr 代码。可以在 Github 上进行 review 和 comment，如果变更代码多的话，可以 clone 到本地用 IDE 进行 review。

7. Merge Pull Request

同事 review 完成后，会 merge pr 到 主分支上，一般是 dev 分支。

下面是三种 merge 的方式：

1. Merge pull request：将 fork 仓库的每一次提交都合并到原仓库，并且还产生了一个 merge commit log。

2. Squash and merge：将多个 commit 合并为一个 commit 添加到原仓库中，会产生一个新的 commit id。

3. Rebase and merge：将 fork 仓库的每一次提交都 rebase 到原仓库，但 github 的 rebase 行为与 git rebase 略有偏差。GitHub 上的 Rebase and merge 始终会更新提交者信息并创建新的提交,也就是产生新的commit id。

可能遇到的问题

Commits 太多或者记录混乱，如何合并 Commits？

很多情况下我们需要去合并 commits，比如你的第一个 commit 里改了100行代码，然后发现少改了1行，这时候又提交了一个 commit，那么第二个 commit 就多余了，需要合并一下。

1. 通过 Git 命令后合并

​ 通过 rebase 命令来完成合并，比较麻烦，下面在 IDE 里进行合比较好用。

2. 通过 IDE 进行合并

按上面页面进行操作后，输入新的 commit message，点 OK，即完成了合并 commit。

Reviewer 提交了修改意见，如何更新 PR?

很多时候，我们提交了一个 PR 后，还需要继续追加 commit，比如提交后发现代码还有点问题，想再改改，或者 reviewers 提了一些修改意见，我们需要更新代码。

一般我们遵守一个约定：在 review 开始之前，更新代码尽量不引入新的 commits 记录，也就是能合并就合并，保证 commits 记录清晰且有意义；在 review 开始之后，针对 reviewers 的修改意见所产生的新 commit，可以不向前合并，这样能够让二次 review 工作更有针对性。

我们只需要在本地继续修改代码，然后通过和第一个 commit 一样的步骤，执行这几个命令：

git add <file>
git commit -s -m "some description here"
git push origin feat-xxx --force上述步骤也可以通过 IDE 进行。

这时候别看 push 的是 origin 的 feat-xxx 分支，其实 GitHub 会帮你把新增的 commits 全部追加到一个未合入 PR 里去。没错，你只管不断 push，PR 会自动更新。

产生了冲突，如何解决？

1. commit 产生了冲突

​ 在 IDE 中解决

2. pr 产生了冲突

​ 在 Github 页面解决

结语

Git 非常流行，也确实好用，是程序员的必备技能。Git 的操作远不止上面介绍的这些，想要研究透彻得花不少时间。不过，如果掌握了上面介绍的知识，足够在日常工作中使用了。如果遇到了问题，可以问问 GPT，能够解决 99% 的问题。

参考资料：

Git 官方文档

MIT 介绍 Git 原理

如何参与开源项目 - 细说 GitHub 上的 PR 全过程

大厂真实 Git 开发工作流程