原文地址：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 來實現業務敏捷性、加速創新並更快地交付功能——這些都是爲了讓我們的業務能獲得更高的收益！
譯後記
我們相信，在企業數字化轉型落地過程中 ，DevOps 是企業軟件開發模式革新的重要支柱。
CODING 作爲國內領先的 DevOps 解決方案提供商，涵蓋了軟件開發從構想到交付的一切所需，支持 Git/SVN 代碼託管，使研發團隊在雲端高效協同，實踐敏捷開發與 DevOps，提升軟件交付質量與速度，幫助企業輕鬆將創意轉化爲創收。
CODING 也會持續關注並分享軟件研發領域最新理念與技術，與 DevOps 工程師一起成長。