[譯] 如何在六個月或更短的時間內成為 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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。