【译】如何高效的使用 Git

原文连接

medium.freecodecamp.org/how-to-use-…

代码昨天仍是运行好好的今天就不行了。

代码被删了。

忽然出现了一个奇怪的 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 代码是最新的。

咱们如今团队就是按照这样的方式进行开发，确实能够尽量的减小代码管理上的问题。

题外话

像以前那篇《如何成为一位「不那么差」的程序员》说的那样，建议你们都多看看国外的优质博客。

甚至尝试和做者交流，通过沟通原做者也会在原文中贴上个人翻译连接。你们互惠互利使好的文章转播的更广。