原文地址：https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-part-3-version-76034885a7ab
原文作者：Igor Kantor
翻译君：CODING 戴维奥普斯
“Close-up of a backlit laptop keyboard” by Markus Petritz on Unsplash
快速回顾
让我们快速回顾一下前文：
简而言之，这个系列文章讲述的是现代 DevOps 的精髓——如何将一个想法尽可能快速地转化上线实现盈利。
具体来说，在第一部分的文章中，我们了解了 DevOps 文化和目标；在第二部分的文章中，我们讲述了如何使用 Terraform 为之后的代码部署奠定基础。因此在本文中，我们将会讨论如何防止这些代码在运行中失去控制(we will discuss how to keep all these pieces of code from completely going haywire all over the place. )，同时还将讨论如何使用 git 来构建和推广你自己的个人品牌。
如图所示，我们现在在 DevOps 旅程的这个位置：
DevOps Journey
为什么要进行版本控制
当我们谈论"版本控制"时我们在谈论什么？
假设你正在开发一款软件，并且在不断的根据需求修改代码，添加或移除某些功能，那么最近的一次更新通常会是一次“突破性的”更新。换言之，不管你上次更新了什么内容，都打破了之前所做的工作。
现在要怎么做？
如果你真的比较老派，那么你可能更倾向于这样命名你的第一个文件：
awesome_code.pl接着你开始做一些修改，同时需要保留有效的内容以防可能需要回退。因此，您将文件重命名为：
awesome_code.12.25.2018.pl这样看起来运行得不错，直到你开始在一天内进行多次更改，最终可能会得到这样的文件名：
awesome_code.GOOD.12.25.2018.pl当然，在专业的开发环境中，你有多个团队在同一代码库上协作，这将进一步打破这个模型。
毋庸置疑，这条疯狂的火车将快速脱轨。
源代码控制
源代码控制：一种将文件保存在集中位置的方法，多个团队可以在一个公共代码库上协同工作。
这并不是个新方法，我能找到的最早提到源代码控制的内容可以追溯到 1972 年，因此将代码集中在一个地方管理的想法肯定是陈旧的。相对较新的方法是所有构建产物都必须版本化，这意味着所有与生产环境相关的内容都必须进行版本控制，能被追踪、审查并且保留历史记录。
此外，强制“所有产品必须版本化”实际上也是迫使你以“自动化优先”的思维方式处理问题。例如，当你决定在你的 Dev AWS 开发环境中通过单击解决复杂问题时，你可以暂停并思考一下，“所有这些都是能以单击实现版本化构建吗？”
答案当然是否定的。虽然可以通过 UI 的快速原型查看是否有效，但这些尝试一定不是长久之计。从长远来看，请确保你使用 Terraform 或其他基础架构作为代码工具来执行所有操作。
所以如果一切都需要版本化构建，那么我们该如何存储和管理这些内容呢？
答案是 git。
Git
在 git 出现前，使用像 SVN 或其他的源代码控制系统通常是笨重的、用户不友好的、非常痛苦的经历。Git 的不同之处在于它包含了分布式源代码控制的概念。换句话说，当你正在处理更改时，你不会将其他人锁定在集中式源代码存储库之外。相反，你正在处理的是代码库的完整副本，然后该副本将会被合并到主存储库中。
请记住，以上是对 git 的工作原理的过度简化，即使知道 git 的内部工作方式是有价值的，并且需要一段时间才能掌握，但就本文而言，这已经足够了。
现在请记住，Git 不像旧的 SVN，它是一个分布式源代码控制系统，多个团队可以在一个共享的代码库上安全地工作。
为什么要这么麻烦？
具体来说，我强烈主张如果不知道 git 的工作原理，你就不能成为一位专业的 DevOps（云）工程师，就这么简单。那么一个人如何学习 git 呢？
我必须说，谷歌搜索“git 教程”有一个拿不准的地方在于可能会同时出现极其全面和极其混乱的教程，但是有一些内容确实好。
我敦促大家阅读、学习和练习的一系列教程是 Atlassian 的 Git 教程。
事实上这些内容都非常好，但有一部分是全世界专业软件工程师都在使用的：Git Workflows。
另一个非常好的教程是 Learn Git Branching。
Atlassian 教程只是阅读和学习，而 Learn Git Branching 是一个互动教程。
无论如何，如果你不明白 git 的工作原理，你就不会在这个行业中走得太远！我不能一次又一次的强调这点：对 git 功能分支如何工作缺乏了解，或者无法解释 Gitflow，这是 99% 有抱负的 DevOps 工程师候选人的失败之处。
这里有一个关键点在于你可以参加面试，不知道 Terraform 或任何最新的流行的基础设施作为代码工具，没关系——你可以在工作中学习它。
但是，不知道 git 及其工作方式是一个表明你缺乏现代软件工程最佳实践的基础知识的信号，无论是否与 DevOps 相关，这向招聘经理发出了这样的信号：你的学习曲线将会非常陡峭。我相信你不想这样。
相反，你自信地谈论 git 最佳实践的能力将告诉招聘经理，你已经具备了一种软件工程的思维方式——这正是你想要展现的形象。
总结一下：你不需要成为世界上最厉害的 git 专家才能成为令人敬畏的 DevOps 工程师，但是你需要深入学习 git 一段时间直到真正掌握，才能自信地谈论相关话题。至少，你应该精通如何：
- Fork 代码仓库
- 创建分支
- 合并来自上游或者后端的更改
- 创建 Pull 请求
接下来要怎么做
现在，一旦你看完了介绍性的 git 教程，请为自己准备一个 GitHub 帐户。
（译者注：如果你在国内，希望使用高效便捷的开发工具以及中文页面，也可以使用 CODING）
一旦拥有你的 Github 帐户后，就开始向它贡献你的代码！无论你学到什么，都需要你编写代码，请确保定期将其提交到 Github。这不仅灌输了良好的源代码控制规则，还可以帮助你建立起自己的个人品牌。
注意：当你在学习如何使用 git 和 GitHub 时，请特别注意 Pull 请求（或 PR，如果你想要酷一点）。
Pull Request, by Vidar Nordli-Mathisen
个人品牌建设
说到酷——一个品牌是向更广阔的世界展示你的能力的一种方式。
目前一种更好的方法是建立一个充实的 GitHub 主页作为你的个人品牌代理形象，现在几乎所有的雇主都会有这样的要求。因此你应该努力拥有一个整洁、精心策划的 GitHub 帐户——你可以将其放在简历上并引以为豪。
在后面的部分中，我们将讨论如何使用 Hugo 框架在 GitHub 上构建一个简单但看起来酷炫的网站。现在，只需要将代码放入 GitHub 就足够了。
之后随着你的经验越来越丰富，你可能会考虑使用两个 GitHub 帐户：一个用于存储你编写的练习代码的资料，另一个用于存储你希望向其他人展示的代码。
做一个总结：
- 学习 git
- 在 Github 上贡献你所学的一切
- 利用第 1 点和第 2 点展示到目前为止你学到的所有东西
- 然后从中获益！
最后一点想法
最后，请记住这个领域的最新发展，例如 GitOps。GitOps 将我们迄今为止讨论的所有想法都提升到了新的层次——通过 git、pull 请求和部署流水线完成所有工作。
请注意，GitOps 和类似它的方法都是与业务方面的内容息息相关的。具体来说，我们使用像 git 这样的复杂工具并不是因为它们很酷，相反，我们使用 git 来实现业务敏捷性、加速创新并更快地交付功能——这些都是为了让我们的业务能获得更高的收益！