[譯] 如何在六個月或更短的時間內成爲 DevOps 工程師，第三部分：版本控制

• 原文地址：How To Become a DevOps Engineer In Six Months or Less, Part 3: Version
• 原文做者：Igor Kantor
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：jianboy
• 校對者：lihanxiang

注意：這是《如何如何在六個月或更短的時間內成爲 DevOps 工程師》系列的第三部分，第一部分請點擊這裏。第二部分點擊這裏。

讓咱們快速回顧一下上期內容。

簡而言之，這一系列文章講述了一個故事。

而這個故事正在學習如何將想法轉化爲金錢，快速 —— 現代化 DevOps 開發的精髓。

具體而言，在第一部分咱們談到了 DevOps 的文化和目標。

在第二部分，咱們討論瞭如何使用 Terraform 爲將來的代碼部署奠基基礎。固然，Terraform 也是代碼！

所以，在這篇文章中，咱們將討論如何防止全部這些代碼徹底失控。劇透，這都是關於 git！

額外獎勵：咱們還將討論如何使用此 git business 來構建和推廣您本身的我的品牌。

做爲參考，咱們從這裏開始：

DevOps 之旅

---

那麼，當咱們談論「版本控制」時，咱們在說什麼？

想象一下，你正在開發一些軟件。您正在不斷更改它，根據須要添加或刪除功能。 一般狀況下，最新的變化將是一次「破壞性」的變化。 換句話說，不管你最後作了什麼，都打亂以前的工做。

怎麼辦？

好。若是您在之前的學校，您可能傾向於將您的第一個文件命名爲：

awesome_code.pl
複製代碼

而後你開始對文件作一些修改，你須要保留有用的東西，萬一你必須恢復它。

所以，您將文件重命名爲：

awesome_code.12.25.2018.pl
複製代碼

這很好。直到有一天你天天進行屢次更改，因此你最終會獲得這樣的結果：

awesome_code.GOOD.12.25.2018.pl
複製代碼

等等。

固然，在專業環境中，您有多個團隊在相同的代碼庫上進行協做，這進一步打破這種文檔備份方案。

毋庸置疑，上面這種文件重命名來版本管理確定行不通。

源代碼控制：一種將文件保存在集中位置的方法，其中多個團隊能夠在公共代碼庫上一塊兒工做。

如今，這個想法並不新鮮。我能找到的最先說起的文章能夠追溯到 1972 年！所以，咱們應該將代碼集中在一個地方的想法確定是老的。

然而，相對較新的是全部開發過程必須被版本化的想法。

什麼意思呢？

這就是說涉及生產環境的全部內容都必須存儲在版本控制中，並受到跟蹤、審覈和記錄歷史更改。

此外，強制執行「全部開發過程必須版本化」的原則實際上迫使您以「自動化第一」的思惟方式處理問題。

例如，當您決定在 Dev AWS 環境中只經過點擊解決複雜問題時，您能夠暫停並思考這麼一個問題：「全部點擊操做都受版本控制了嗎？」

固然，答案是「不」。所以，雖然能夠經過 UI 進行快速原型查看是否有效，但這些努力必須是短暫的。從長遠來看，請確保您使用 Terraform 或其餘架構即代碼工具來執行全部操做都受版本控制。

好的，因此若是一切都受版本控制，那麼咱們如何存儲和管理這些東西呢？

答案是 git。

在 git 出現以前，使用像 SVN 或其餘的源代碼控制系統是笨重的，不是用戶友好的，而且一般是很是痛苦的經歷。

git 的不一樣之處在於它包含分佈式源代碼控制的概念。

換句話說，當您正在處理更改時，您不會將其餘人鎖定在集中式源代碼存儲庫以外。相反，您正在編寫代碼庫的完整副本。而後該副本會 merged 進入 master 存儲庫。

請記住，以上是對 git 如何工做的粗略過分簡化。但就本文而言，這已經足夠了，即便知道 git 的內部工做方式既有價值又須要一段時間才能掌握。

xkcd.com/1597/

如今，請記住，git 不是像舊版的 SVN 同樣。它是一個分佈式源代碼控制系統，多個團隊能夠安全，可靠地在共享代碼庫上工做。

這對咱們意味着什麼？

具體來講，若是沒有使用 git 版本管理而自稱做專業的 DevOps（雲）工程師，我嚴重懷疑你的能力。就這麼簡單。

好的，那麼如何學習 git 呢？

我必須說，Google 搜索 「git 教程」的區別在於它提供的教程很是全面但很是使人困惑。

可是，有一些很是很是好。

我推薦你們閱讀，學習和練習的一系列教程是 Atlassian’s Git Tutorials。

事實上，它們都很是好，但特別是世界各地的專業軟件工程師使用的部分：Git Workflows。

我再怎麼強調也不爲過。一次又一次地，缺少理解 git 分支是如何工做的，或者沒有解釋 Gitflow 是什麼讓 99% 有抱負的 DevOps 工程師落選的緣由。

這是關鍵。你能夠參加面試，即便不知道 Terraform 或者最新的架構及代碼是什麼，不要緊 — 你能夠在工做中學習它。

不知道 git 及其工做方式代表你缺少現代軟件工程最佳實踐的基礎知識，DevOps 與否。這向招聘經理髮出信號，代表你的學習曲線很是陡峭。你不想發出信號！

相反，您自信地談論 git 最佳實踐的能力告訴招聘經理您首先要具有軟件工程思惟模式 —— 這正是您想要應用到工做中的思惟。

總而言之，你不須要成爲世界上最重要的 git 專家，來得到使人敬畏的 DevOps 角色，但你確實須要在一段時間內生活和呼吸 git，才能自信地談論正在發生的事情。

至少，你應該精通以下：

1. Fork 一個倉庫
2. 建立分支
3. 合併兩個不一樣的 commit
4. 建立 Pull 請求

如今，一旦您完成介紹性的 git 教程，請獲取 GitHub 賬戶。

注意：GitLab 也能夠，但在撰寫本文時，GitHub 是最流行的開源 git 存儲庫，所以您確定但願和其餘人分享。

得到 GitHub 賬戶後，開始爲其提供代碼！不管你學到什麼，都須要你編寫代碼，請確保按期將它提交給 GitHub。

這不只能夠灌輸良好的源代碼控制思想，還能夠幫助您創建本身的我的品牌。

注意：當你學習如何使用 git + GitHub 時，要特別注意 Pull Requests（也叫 PRs，若是你想變酷）。

Pull Request, by Vidar Nordli-Mathisen

---

品牌：向更廣闊的世界展現您的能力的一種方式。

這種方式（目前，更好的方式之一！）是創建一個 GitHub 帳戶，做爲您的品牌表明。這些天幾乎全部的面試官都會要求求職者有 GitHub 帳戶。

所以，您應該努力擁有一個整潔、精心策劃的 GitHub 賬戶 — 您能夠將其放在簡歷上併爲此感到自豪。

在後面的部分中，咱們將討論如何使用 Hugo 框架在 GitHub 上構建一個簡單但酷炫的網站。如今，只需將代碼放入 GitHub 便可。

稍後，隨着您的經驗愈來愈豐富，您可能會考慮使用兩個 GitHub 賬戶。一個用於存儲您編寫的練習代碼的我的資料，另外一個用於存儲您想要向其餘人展現的代碼。

總結一下：

• 學習 git
• 將您學到的全部知識貢獻給 GitHub
• 利用＃1和＃2做爲迄今爲止所學到的全部知識的展現
• 從中受益！

最後，請記住這個領域的最新發展，例如 GitOps。

GitOps 將咱們迄今爲止討論的全部想法提高到新的水平 — 一切都經過 git、pull requests 和管道的部署。

請注意，GitOps 和相似的工具應用於商業方面的事情。具體來講，咱們不是在使用像 git 之類的複雜東西，由於它們很酷。

相反，咱們使用 git 來實現業務敏捷性，加速創新並更快地交付功能 —— 這些均可以讓咱們的業務最終賺到更多錢！

目前爲止就這樣了！

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。