git 基礎用法梳理

推薦大家讀一下大佬的《Git 原理詳解及實用指南》，簡單易懂，成功讓我捨棄了圖形化工具，轉入命令列操作。

在我們日常的專案開發中，版本管理不可避免，一般常用的版本控制系統有兩個 svn 和 git ，至於他們的區別，有興趣的同學請自行研究。本文主要通過幾個 git 命令的使用，結合專案開發的實際過程，來聊一聊 git 的基本使用方法。

一、初始化本地專案

當我們新接手一個專案時，首先要做的就是要從遠端倉庫拉取專案程式碼。

git clone ***** （* 為遠端倉庫地址）
複製程式碼

以上是已有遠端倉庫時的做法，可是如果是一個全新的專案，還沒有遠端程式碼倉庫，那麼我們就需要先新建一個遠端倉庫，然後通過 git clone 命令來拉取專案程式碼。
你也可以先在本地初始化專案，然後關聯到遠端倉庫：

git init   # 初始化本地的倉庫，會生成.git檔案
git add .  # 把所有改動新增到暫存區
git commit -m "first commit" # 編寫 commit 資訊
git remote add origin https://github.com/wumouren/git-demo.git # 關聯本地倉庫到遠端
git push -u origin master # 推送本地更新到遠端倉庫，並設定預設推送路徑
複製程式碼

如圖：

1、初始化本地倉庫

2、建立遠端倉庫，獲取遠端倉庫地址

3、新增本地檔案，新增到暫存區，並編寫 commit 資訊，提交本地更新

4、關聯本地倉庫到遠端倉庫，並設定預設推送路徑，推送本地更新到遠端

經過上述步驟，我們再次開啟遠端倉庫，發現本地更新已經成功推送到了遠端倉庫：

我們用寄快遞來類比下 git 提交的過程：

git add . # 新增修改到暫存區   -->   類似與我們把需要寄出的快遞挑揀出來

git commit -m '描述' # 編寫 commit 資訊 -->    相當於我們把快遞打包，並填寫快遞單

git push # 推送本地更新到遠端倉庫   -->   相當於我們寄出快遞

複製程式碼

以上，我們簡單的過了一遍 git 的使用流程，關於所用到的一些命令，在下邊我們再來繼續探討。

二、新增檔案改動到暫存區

當我們在本地進行需求開發時， git 總能追蹤的程式碼的改變，我們可以通過 git status 來檢視：

當我們修改 a.js 的內容，並新增 b.js 後，通過 git status 我們看到，控制檯已經清晰的告訴我們，現在本地倉庫有了哪些改變 。 我們可以通過 git add 來新增修改到暫存區。之後，我們再用 git status 來看下檔案狀態：

我們看到，通過 git add 把修改內容新增到暫存區後，所有的修改都變成了綠色，控制檯提示資訊也發生了改變。

關於 git add 的引數：這裡有更多用法

git add <path>（可寫多個） # 提交指定檔案改動到暫存區

git add . # 提交所有被刪除、被替換、被修改和新增的檔案改動到資料暫存區等同於 git add -A
# 另：一些博文中說 git add . 只提交所有修改的和新建的檔案改動到暫存區--即刪除的檔案不會被新增，可我實驗多次，發現並不是這樣，猜測和 git 版本有關，我的版本 2.15.2

git add -u <===> git add –update  # 提交所有被刪除和修改的檔案改動到資料暫存區（即新增的檔案不會被新增）

git add -A <===>  git add –all   # 提交所有被刪除、被替換、被修改和新增的檔案改動到資料暫存區（綜合了 git add . 和 git add -u）
複製程式碼

當我們修改了多個檔案後，想提交程式碼，可裡邊偏偏又有一個檔案改動我們不想提交，這時我們需要用到另一個命令：

git reset 檔案路徑（可寫多個）
複製程式碼

如圖：

上圖中，我們新增了三個檔案改動，然後通過 git add 把檔案改動提交到暫存區，可是我們突然又覺得有些檔案改動我們還不想提交，所有又通過git reset 命令撤銷了相關提交。
以上操作僅做相關命令的演示，在實際的開發中，還望大家靈活使用。

關於 commit

我們把改動新增到暫存區後，下一步就是要 commit（類似與挑揀完需要快遞的東西后，要進行打包填寫快遞單）。 我們可以每一次 commit 後都進行 push 操作，也可以多次 commit 後，再進行 push 操作。我們可以 git log 來檢視 commit 記錄：

如圖，我們通過三次 commit 分別提交了 a.js 、 b.js 、 c.js。 然後通過 git log檢視，可以清晰的看到我們三次 commit 分別的 commit 描述資訊。（可以通過連續兩個大寫的 Z 來退出 git log）
如果我們突然想修改最後一次 commit 的描述資訊，那麼我們將會用到一個新的命令引數 git commit --amend ：

當我們輸入git commit --amend 後，點選會車，我們會進入一個編輯頁面。

在這個頁面中我們可以修改 commit 描述資訊，然後儲存、退出。

具體操作為：
點選 i 建，進入插入模式，開始編輯資訊。
完成後 按 esc 鍵，退出編輯模式。
然後輸入英文 :wq! 儲存退出

# 不熟悉命令列操作的同學，請自行研究
複製程式碼

修改完 commit 資訊後，我們再次通過git log命令來檢視 commit 記錄：

假定我們想修改的描述資訊不是最後一次 commit 的 d.js ，而是 b.js ，那麼，我們將會用到另一個命令 git rabase -i：

我們將 b.js 前的 pick 標識修改為 edit：

回車後我們發現分支已經不在 master 上了：

我們再次輸入 git log 命令，可以看到，最近一次的 commit 已經變成了 b.js :

我們重複修改 d.js 的操作，之後根據命令列提示的資訊，我們輸入git rebase --continue命令：

我們再次列印 commit 記錄,可以看到，b.js 成功被修改：

# 以上只是其中一種方法，其他方法請自行研究。
複製程式碼

pull、push 與 衝突

git pull 用於從遠端倉庫獲取最新程式碼。
依舊用寄快遞來類比，當我們將快遞打包好並填好快遞單後，在往寄存櫃中存放之前，先要知道那些格子是被放過東西的，那些是還沒有放東西的，我們的快遞只能放在還沒有放東西的格子中！

git pull 命令就可以看作是更新了最新的儲物格資訊。

假定，你想把快遞放在第一排第一列，如果這個儲物格是空的，自然可以放進去。可是，如果這個儲物格已經放過了東西，你還想往裡放，這樣，就產生了衝突。git 中的衝突，大致也是這麼個意思。

假定我們的同事小A，在和你協作開發，他也修改了 a.js 檔案，然後提交了程式碼，這樣在你進行 git push時，便會產生衝突。

# 左側是我們正在編輯的 a.js ，右側是 小A 的修改的 a.js
複製程式碼

我們看到，兩人在開發的時候都修改了相同位置的程式碼，然後小A開發完後，進行了提交：

然後我們再來提交自己的程式碼：

很明顯，在程式碼中產生了衝突。這時，我們就要和小A來交流，來解決衝突。

和小A交流後，我們決定保留雙方的程式碼，自己就刪除了程式碼中那些奇奇怪怪的 hash ，重新進行了一次提交：

這樣，一次簡單的衝突就解決了。

當我們 push 完成後，遠端倉庫的程式碼已經再次發生了改變，小A突然想起來還有一個需求要修改，可是在修改前卻忘記了更新原生程式碼，於是在完成修改之後，發現直接 push 時報了錯：

控制檯提示我們在 push 之前要先 pull ，我們按照提示輸入 pull 命令：

控制檯中又出現了那個我們熟悉的 commit 資訊編輯介面：

我們儲存退出後，重新 push ，就可以了。

注意的地方

以上，簡單說了兩個常見的衝突，當然在實際開發中，還會出現各種奇奇怪怪的問題。
在有問題時，我們不要慌（之前我會很慌，不知道該怎麼辦，瞬間手忙腳亂）應該多留意控制檯資訊，然後查詢解決辦法。
在提交程式碼前一定要先 pull ，把原生程式碼更新到最新，然後再 push , 這樣做可以避免覆蓋別人的程式碼。
複製程式碼

分支與合併分支

在專案的開發中，常常會需要有多個分支。我們可以通過git branch命令來新建分支：

git branch        # 檢視分支

git branch 分支名   # 新建分支

git checkout 分支名 # 切換分支
複製程式碼

如圖：

我們在 2018 分支上再做些修改，並提交程式碼：

通過 git log 我們看到，新提交的 2018 已經存在提交記錄裡了：

我們再切換到 master 分支，發現，資訊為 2018 的提交記錄並不存在，相應的改動當然也不存在：

這時我們就需要合併分支，把 2018 分支上的改動合併到 master 分支上，我們需要用到一個新的命令：git merge。

我們切換到 master 分支上，然後輸入git merge，如圖：

我們看到，在 2018 分支上的改動，已經出現在 master 分支上了。

最後

本文旨在梳理 git 使用的基本知識，對於一些命令的使用和描述並不全面，更多高階的用法，還望各位自行研究，這裡不做贅述。
以上，如有描述不正確的地方，還望批評指正！