Git：瞭解版本控制的核心概念

做者：Bob Ziroll

翻譯：瘋狂的技術宅

原文：www.freecodecamp.org/news/git-th…

未經容許嚴禁轉載

Git 是全部開發人員工具箱中的重要工具。

例如就在前幾天，我大約只用了 20 分鐘就解決了一個已經投入生產環境的重大問題（徹底是個人錯）。若是沒有 Git，這可能須要幾天的時間來修復。

所以，讓咱們花些時間真正瞭解 Git 最基本的功能：準備和提交。

注意：本文不包含與 GitHub 相關的任何內容，它是第三方在線Web服務，容許你在雲端備份用 Git 保存的代碼。 Git 是本地的，GitHub 是一個基於雲的應用，它們是兩個徹底不一樣的東西，儘管目的相同。

什麼是版本控制？

若是你年齡夠大，可能還記得 Google Drive/Docs/Sheets 以前的世界，你可能會這樣作：

處理羣組項目會致使多人嘗試對原始文檔的多個副本進行編輯，從而致使許多重複。若是兩我的同時進行編輯，則必須有人手動完成全部操做並將這些編輯組合在一塊兒。

沒有什麼好辦法來控制項目的不一樣版本。這就像是在狂野的西部同樣。🤠+😢

Git解決了這個問題💡

也許你已經在本身的項目中增長了一個新功能，破壞了之前工做得很好的東西，但不知道在哪裏找到錯誤或如何解決它。你已經在編輯器中關閉了文件，所以就不能再使用「撤消」了。

Git解決了這個問題💡

好的，可是 Git 是怎樣解決這些問題的？

Git 的核心功能是在文件中建立保存點。我以爲這些保存點就像在視頻遊戲中同樣，即便你在那以後搞砸了，老是能夠回來再試一次而沒必要從新開始。

Git 還有不少使人敬畏的方面，可是它的所有內容的核心是：在代碼中建立保存點，若是須要，能夠在以後返回。

Git 是怎樣工做的？

Git 的這個核心功能（在你的項目中建立保存點）分爲兩個階段：

1. 將事物（更改的代碼和文件）添加到要在時間線中提交（保存）的臨時區域，以及
2. 實際上提交（保存）的那些東西。

強制性對比

這兩個階段，好像你正在建立一個老式的相冊，一個用於打印照片並將其放入真正的相冊。若是你由於太年輕沒有見過的話，就是這樣的：

首先，你用相機拍了一堆照片。拍攝照片並不會影響相冊，由於你始終能夠選擇要包含在相冊中的照片。你會獲得拍攝得很差的照片，並在必要時從新拍攝。

下一步，你能夠選擇要在相冊中保存哪一張照片。想象一下，你已將它們打印出來，而後將它們放置在在相冊中的空白頁面旁邊。你正在建立一種「臨時區域」，你還沒有將照片粘貼到相冊中的頁面上，可是你準備立刻就這樣作。

最後，一旦你準備好了，就把你的照片粘貼到頁面上，並將它們粘合在一塊兒。一個好的相冊要包含這些照片中事件的某種描述或標題。

完成操做後，你能夠隨時回到相冊中的這個頁面，回憶你當時生活中的狀況（不管好壞）。

這與Git有什麼關係？

讓咱們將這個類比與 Git 聯繫起來。

• 拍攝照片就像修改項目文件（編寫代碼、建立文件或刪除文件）。
• 在相冊中選擇所需的照片就像將更改添加到「臨時區域」。
• 將照片粘貼到相冊頁面就像把修改提交（保存）到更改時間線中。

讓咱們逐一解釋w。

拍攝照片就像修改項目文件同樣

拍攝照片就像對項目進行更改：編寫新代碼、添加圖像、刪除舊文件等等。你正在建立最終要在 Git 提交中保存的內容（「保存點」）。它仍然是一項正在進行中的工做，你能夠隨時編寫、重寫或刪除任何你想要的內容，而無需「永久」保存它們。

Git 目前正在作的惟一事情是觀察自上次提交（保存）代碼以來是否有什麼變化。若是你添加一行代碼而後再刪它，Git 將會認爲總體沒有發生任何變化。若是你在幾十個文件中編寫 500 行代碼，Git 可以確切地知道都有哪些代碼行被添加到哪些文件中，並在其內存中跟蹤這些變化。在你告訴它以前，它不會對變動的時間表作出任何提交，但它會密切關注你的操做。

注意：請記住，如今咱們指的是一個與保存更改到硬盤上徹底不一樣的過程。現代文本編輯器能夠每隔一秒左右保存你的代碼，但這不是咱們在這裏所提到的。當我提到使用 Git 「保存」時，個人意思是建立一個提交，將你的更改保存到時間軸。

在相冊中選擇所需的照片就像將項目更改添加到「臨時區域」

在 Git 中，這是在代碼中建立新提交以前發生的階段。此過程稱爲「添加到暫存區域」。添加到暫存區域不會建立提交，它只是準備提交。

將一些文件添加到暫存區域後，你可能會發現仍要作一些更改。沒問題！因爲此時 Git 還沒有實際保存（提交）任何內容，你能夠簡單地進行所需的新更改，而後將這些更改添加到臨時區域，即便這些更改發生在與先前添加的文件相同的文件中。這就像拍攝一些你決定要添加到相冊頁面並打進行印的新照片。

將照片粘貼到相冊中就像提交代碼同樣

這是建立「保存點」（提交）的第二個（也是最後一個）階段。建立提交時有一個主要要求：你必須包含信息。在相冊中，你能夠撰寫標題或信息，以便向將來的觀看者提供關於這些照片對你意味着什麼的信息。在 Git 中，你須要編寫一條消息來描述你要保存到代碼庫中的更改。

若是你寫了一個糟糕的提交信息，那麼回顧你的代碼歷史對包括你本身在內的任何人都沒有幫助。 （若是你不知道這些變化是什麼，那麼「作出一些改變」的消息有什麼用呢？想象一下，在相冊中找到一個頁面，上面寫着「這裏有一些人......」）始終使用良好的描述性提交消息來描述你添加到代碼庫中的功能或修復。

行動

例子已經足夠了，如今讓咱們開始吧！

安裝

首先，你可能已經安裝了Git。打開終端或命令提示符並嘗試運行 git --version。若是它顯示了版本號，請跳事後面這一步。若是它提示不知道你的 git 是什麼意思，你須要安裝它。 請按照如下說明爲你的操做系統安裝。

建立一個Git倉庫

Git 只知道跟蹤你設置爲 Git 存儲庫的項目。在上面的比喻中，若是咱們首先沒有相冊，就沒法將照片粘貼到相冊中。

當你準備開始一個新項目時，應該執行的第一步（建立項目文件夾以後）是運行：

git init
複製代碼

這容許 Git 當即開始跟蹤你對項目所作的任何更改。在底層它會建立一個新的隱藏 .git 文件夾，其中的全部內容都須要跟蹤你的更改。你幾乎不須要進入這個文件夾，除非你正在設置一些高級的東西。

對項目進行更改

對於下面的教程，我將盡量保持簡單 —— 一個項目文件夾，它是一個帶有單個名爲 README.md markdown 文件的 Git 倉庫。你能夠想象我對 README 文件所作的每一個更改都表明了一些新功能或者幾10、幾百行新代碼。👌🏻😉

基本命令

git status

我想將此視爲「理智檢查」，用來幫助我瞭解 Git 目前正在進行的工做。 （例如它注意到了哪些變化，是否一切正常等等）

它告訴我正處在主分支上（我會另外再寫一篇關於分支的文章），我以前沒有提交過，並且如今沒有任何東西須要提交。 （意思是，Git 沒有看到任何須要要保存的文件夾）。

如今我將添加 README.md 文件並再次運行 git status：

Git 看到我在項目中添加了一個新文件。酷！如今這個使人敬畏的新項目正在進行中，讓咱們建立一個保存點。

git add

git add 命令是把東西放在臨時區域的方式。就像打印咱們拍攝的照片同樣，而後將它們粘貼在咱們的相冊頁面中。可是咱們須要告訴 Git 咱們想要添加到暫存區域。 （若是隻輸入 git add 會提示你沒有指定任何東西，因此不會添加內容。）我將用 Git 添加文件的文件名：

git add README.md
git status
複製代碼

再次使用 git status ，顯示在暫存區域有一個新文件，但它如今變成了綠色！這是提示你它已經被添加到臨時區域的簡單方法。

基本上 git add README.md 告訴 Git 「我但願包括自上次提交後包含在即將提交中的 README.md 所作的全部更改。」

可是，將文件一次一個地添加到暫存區域是很麻煩的，特別若是有許多任務須要你去處理不少文件的話。你大可沒必要記住並指定正在處理的每一個文件，而是可使用「一網打盡」的方式，它會自動添加你對暫存區域進行更改的每一個文件。個人首選方法是：

git add -A
複製代碼

（-A標誌表示將全部帶有更改標記的文件添加到暫存區域）。

注意：你常常會看到人們用 git add . 來實現將全部更改添加到暫存區域。雖然這有效，但它要求你位於項目根目錄中以確保獲取全部更改。 （. 是「當前目錄」的簡寫）。所以，若是你 cd 進入嵌套目錄但對該目錄外的文件進行了更改並嘗試使用 git add .，那麼在嘗試將這些文件添加到暫存區域時，將會錯過這些更改的文件。可是不管你目前在終端中的哪一個位置，git add -A 都適用於整個項目。

git commit

一旦你準備好建立一個提交，就能夠用 git commit 命令。可是，還記得你是如何添加備註的嗎？若是你只是運行 git commit 並按回車鍵，將會彈出一個基於終端的編輯器，如 Vi 或 Nano，以填寫該提交的信息。

你也能夠用 -m 標誌，而後在引號中使用字符串消息，使你的 git commit 與消息保持一致。像這樣：

git commit -m "Added some really important information to the README"
複製代碼

假設在提交以前其餘全部內容都已就緒，如今就已經使用 Git 成功提交了代碼！如今你有了一個檢查點，若是從這裏出現問題，你能夠隨時返回。

讓咱們以 gif 的形式再看一下這個過程：

注意：gif 使用 git add，但我認爲應該用 git add -A 更精確。此外，要使用更好的提交信息！請原諒個人錯誤

git log

你能夠經過運行 git log 來查看提交歷史記錄。使用箭頭鍵，你能夠及時向前和向後滾動來檢查提交日期、消息和做者（提交者）。隨之一塊兒出現的是「提交哈希」，其實質上是提交的惟一ID，能夠在之後須要時用於引用它。

時間旅行

「因此你一直在談論 Git 如何能讓我及時向後跳躍......我該怎麼作呢？」

git checkout

術語 「checkout」 是指從一個提交切換到另外一個提交的過程。還記得每一個提交收到的惟一ID（「哈希」）嗎？我能夠回顧一下個人提交歷史，選擇其中一個惟一的提交哈希值，而後用 git checkout 命令查看它。若是我想看的提交有一個 a2 的哈希值（完整它們比這長得多 - 就像 0c9b8f7c23dea4cf0a0285f14211124b6d5891e9），能夠運行：

git checkout a2
複製代碼

忽然之間，個人整個代碼庫的時間線縮短了，一切都會像我提交後的那樣。 （這可能很嚇人，由於看起來你可能已經丟失了自提交以來的全部更新，但不要擔憂！他們還在！）

以 gif 形式說明：

注意，第 3 次提交及其中的更改仍然徹底存在。能夠用 git checkout a3 或（更常見的）git checkout master 返回到該提交，以恢復全部更改。

如今你回來了，你會看到來自 Git 的消息。就像是：

Note: checking out 'a2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at a2 Another Message
複製代碼

"Detached HEAD" 聽起來比如今更可怕。🤢

在這種狀態下，你再也不使用 master 分支，也就是說你能夠在這裏進行實驗性更改甚至建立新的提交，全部這些操做都不會丟失你在 master 分支上的代碼（上面的例子提交哈希 a3 ）。

一樣，我計劃在另外一個時間覆蓋分支，但這只是爲了說明 Git 在保存多個版本的代碼時是一個很是強大的工具。

結論

關於 Git 你能夠學到一百萬個東西，但若是不瞭解核心概念，它總會顯得有點神祕。

可是，若是你真的想學習並熟悉 Git，那麼你最好的去實操並進行實驗。

這意味着你要作的不只僅是閱讀文章。因此請在一個空文件夾中建立一個新的 Git 存儲庫，開始添加文件，用 git status 和 git log 來看看是什麼樣的，並考慮下載 Sourcetree 以便在你搞亂項目的時候能夠經過可視化來觀察你存儲庫的狀態。

歡迎關注前端公衆號：前端先鋒，免費領取前端工程化實用工具包。