• 【译】如何高效的使用 Git
• Git 工作流
• 前言
• Git 开发流程
  • Master 分支
  • Release(发布) 分支
  • Feature(功能分支) branch
  • Pull request
  • 代码冲突 😠
• 还是 Master 分支

【译】如何高效的使用 Git

原文链接

代码昨天还是运行好好的今天就不行了。 代码被删了。 突然出现了一个奇怪的 bug，但是没人知道怎么回事。

如果你出现过上面的任何一种情况，那本篇文章就是为你准备的。

除了知道 git add, git commit , git push 之外，Git 中还需要其他重要的技术需要掌握。长远来看对我们是有帮助的。这里我将向你展示 Git 的最佳实践。

Git 工作流

当有多个开发者同时涉及到一个项目时那么就非常有必要正确使用 Git 工作流。

这里我将介绍一种工作流，它在一个多人大型项目中将非常有用。

前言

突然有一天，你成为了一个项目的技术 Leader 并计划做出下一个 Facebook。在这个项目中你有三个开发人员。

1. Alice：一个开发小白。
2. Bob：拥有一年工作经验，了解基本开发。
3. John：三年开发经验，熟练开发技能。
4. 你：该项目的技术负责人。

Git 开发流程

Master 分支

1. Master 分支应该始终和生产环境保持一致。
2. 由于 master 和生产代码是一致的，所以没有人包括技术负责人能在 master 上直接开发。
3. 真正的开发代码应当写在其他分支上。

Release(发布) 分支

1. 当项目开始时，第一件事情就是创建发布分支。发布分支是基于 master 分支创建而来。
2. 所有与本项目相关的代码都在发布分支中，这个分支也是一个以 release/ 开头的普通分支。
3. 比如这次的发布分支名为 release/fb。
4. 可能有多个项目都基于同一份代码运行，因此对于每一个项目来说都需要创建一个独立的发布分支。假设现在还有一个项目正在并行运行，那就得为这个项目创建一个单独的发布分支比如 release/messenger。
5. 需要单独的发布分支的原因是：多个并行项目是基于同一份代码运行的，但是项目之间不能有冲突。

Feature(功能分支) branch

1. 对于应用中的每一个功能都应该创建一个独立的功能分支，这会确保这些功能能被单独构建。
2. 功能分支也和其他分支一样，只是以 feature/ 开头。
3. 现在作为技术 Leader，你要求 Alice 去做 Facebook 的登录页面。因此他创建了一个新的功能分支。把他命名为 feature/login。Alice 将会在这个分支上编写所有的登录代码。
4. 这个功能分支通常是基于 Release(发布) 分支 创建而来。
5. Bob 的任务为创建添加好友页面，因此他创建了一个名为 feature/friendrequest 的功能分支。
6. John 则被安排构建消息流，因此创建了一个 feature/newsfeed 的功能分支。
7. 所有的开发人员都在自己的分支上进行开发，目前为止都很正常。
8. 现在当 Alice 完成了他的登录开发，他需要将他的功能分支 feature/login 发送给 Release(发布) 分支。这个过程是通过发起一个 pull request 完成的。

Pull request

首先 pull request 不能和 git pull 搞混了。

开发人员不能直接向 Release(发布) 分支推送代码，技术 Leader 需要在功能分支合并到 Release(发布) 分支之前做好代码审查。这也是通过 pull request 完成的。

Alice 能够按照如下 GitHub 方式提交 pull request。

在分支名字的旁边有一个 “New pull request” 按钮，点击之后将会显示如下界面：

• 比较分支是 Alice 的功能分支 feature/login。
• base 分支则应该是发布分支 release/fb。

点击之后 Alice 需要为这个 pull request 输入名称和描述，最后再点击 “Create Pull Request” 按钮。

同时 Alice 需要为这个 pull request 指定一个 reviewer。作为技术 Leader 的你被选为本次 pull request 的 reviewer。

你完成代码审查之后就需要把这个功能分支合并到 Release(发布) 分支。

现在你已经把 feature/login 分支合并到 release/fb，并且 Alice 非常高兴他的代码被合并了。

代码冲突 😠

1. Bob 完成了他的编码工作，同时向 release/fb 分支发起了一个 pull request。
2. 因为发布分支已经合并了登录的代码，这时代码冲突发生了。解决冲突和合并代码是 reviewer 的责任。在这样的情况下，作为技术 Leader 就需要解决冲突和合并代码了。
3. 现在 John 也已经完成了他的开发，同时也想把代码合并到发布分支。但 John 非常擅长于解决代码冲突。他将 release/fb 上最新的代码合并到他自己的功能分支 feature/newsfeed （通过 git pull 或 git merge 命令）。同时他解决了所有存在的冲突，现在 feature/newsfeed 已经有了所有发布分支 release/fb 的代码。
4. 最后 John 创建了一个 pull request，由于 John 已经解决了所有问题，所以本次 pull request 不会再有冲突了。

因此通常有两种方式来解决代码冲突：

• pull request 的 reviewer 需要解决所有的代码冲突。
• 开发人员需要确保将发布分支的最新代码合并到功能分支，并且解决所有的冲突。

还是 Master 分支

一旦项目完成，发布分支的代码需要合并回 master 分支，同时需要发布到生产环境。

因此生产环境中的代码总是和 master 分支保持一致。同时对于今后的任何项目来说都是要确保 master 代码是最新的。

我们现在团队就是按照这样的方式进行开发，确实可以尽可能的减少代码管理上的问题。