轉自：https://www.cnblogs.com/qcloud1001/p/9796750.html

Git 是什麽？

Git 是一個分布式的代碼管理容器，本地和遠端都保有一份相同的代碼。 Git 倉庫主要是由是三部分組成：本地代碼，緩存區，提交歷史，這幾乎是所有操作的本質，但是為了文章更加簡單易懂，就不圍繞這塊展開了，有興趣的可以去了解下。 開門見山，我們直接來說說 Git 有哪些常見的操作。

Git 有哪些常規操作？

我們簡單說說Git有哪些常規操作，能夠讓我們應付簡單的開發需求。

克隆代碼

? 克隆遠端代碼

git clone + 遠程庫地址

? 查看本地的代碼狀態

// 可以明確的呈現出本地倉庫的狀態
// 哪些文件發生改動，哪些文件已經提交到本機
// 以及一些操作指示。
git status
 

? 同步遠端分支變化

// 拉取指定分支的變化
git fetch origin master 
// 拉取所有分支的變化
git fetch 
// 拉取所有分支的變化，並且將遠端不存在的分支同步移除【推薦】
git fetch -p

? 同步遠端代碼變化。

// 都是先 git fetch，然後執行合並操作
// 不同的是，git pull 執行的是 git merge，git pull -r 執行的是git rebase
git pull origin master 
git pull -r origin master

關於 git merge 和 git rebase 各自的優劣，後文會詳細介紹。

這部分主要介紹了關於代碼克隆，同步遠端代碼變化的相關操作。接下來，我們看看關於本地代碼的一些操作。

操作 commit

首先我們要明確一個概念：就是每個 commit 都是一份完整的代碼狀態，用一個 commitID 來唯一標誌。

從某個角度上來說，Git維護的就是一個commitID樹，分別保存著不同狀態下的代碼。 所以你對代碼的任何修改，最終都會反映到 commit 上面去。

? 新增 commit

// 添加文件到緩存區，然後提交到本地倉庫
git add files
git commit -m ‘提交備註‘

? 撤銷 commit

// 會將提交記錄回滾，代碼不回滾
git reset b14bb52

// 會將提交記錄和代碼全部回滾
git reset --hard b14bb52

// 將部分代碼文件回滾
git checkout -- files
 

? 合並 commit 合並 commit，本質上合並兩份不同狀態下的代碼。

// Git 提供了兩種合並 commit 的方式
git merge master
git rebase master

那麽 git rebase 和 git merge 到底有什麽區別呢？ merge是兩個分支處理沖突後，新增一個 commit 追加到master上。 rebase是將someFeature分支上的commit記錄追加到主分支上，值得註意的是，這個時候他的commit其實已經發生變化。

相對來說，git merge 處理沖突更直接，而git rebase 能夠保證清晰的 commit 記錄。

合並 commit 的時候，通常會發生沖突。 可以全局搜索特殊字符比如<<<，找到需要處理的代碼位置，然後認真分析應該保留哪一部分代碼。

在團隊協作的時候，分支是必不可少的。那麽應該如何對分支進行操作呢？

操作分支

所謂的分支其實就是一個指向 commitID 的指針，你可以去.git/refs/heads裏去看看。

通常情況下，我們建議分支至少能夠明確的標記功能名稱，如果能標記用戶就更好了，比如qixiu/feature。

? 查看分支

可以同時看到本地分支和遠端分支，配合上前文介紹的git fetch -p可以第一時間查看到最新的分支信息。

? 新增本地分支 其實就是創建一個指針指向某一個 commitID。

// git branch qixiu/feature + git checkout qixiu/feature
// 從當前分支新增一個新的分支qixiu/feature
// 一般情況下，我們應該從master或者其他穩定分支來新增分支
git checkout -b qixiu/feature // 新建分支
git checkout qixiu/feature // 切換分支

? 刪除本地分支 其實就是移除一個指向 commitID 的指針。

// 刪除本地分支，如果本地還有未合並的代碼，則不能刪除
git branch -d qixiu/feature
// 強制刪除本地分支
git branch -D qixiu/feature

? 新增遠端分支 通常情況下，我們是新建本地分支，然後更新到遠端的方式來新增一個遠端分支

git push origin qixiu/feature

? 刪除遠端分支 同樣，我們也是通過更新到遠端的方式來刪除一個遠端分支

// 等同於git push origin -d qixiu/feaure
git push origin :qixiu/feature

簡單匯總一下

上面說的可能有些分散，這兒簡單總結一下有哪些經常使用的操作：

git status // 查看本地代碼狀態
git add files // 添加代碼到緩存區
git commit -m ‘提交內容的備註‘ // 提交代碼到本地倉庫
git checkout -b branchName // 不加-b就是普通切換分支
git fetch -p // 同步遠端分支狀態
git pull -r origin branchName // fetch遠端代碼到本地，並且以rebase的方式合並代碼
git push origin branchName // 更新本地代碼到遠端

以上幾條命令已經能夠應付日常的操作，稍微復雜一些的場景後文會介紹

基於基本操作，在實際項目中，我們應該怎麽利用 Git 實現協作呢？

Git 有哪些比較好的實踐？

Git 有一些成熟的開發流程，比較主流的有兩種：基於功能分支的開發流程 和 GitFlow開發流程。 相對來時，我更推薦前者，如果是復雜的大型項目，推薦GitFlow開發流程。 接下來，簡單介紹下這兩種協作模式。

基於功能分支的協作模式

基於功能分支的開發流程其實就是一句話：用分支來承載功能開發，開發結束之後就合並到 master 分支。 他的優點是能夠保證master分支的整潔，同時還能讓分支代碼邏輯集中，也便於 CodeReview。

分支命名規範

推薦使用如下格式：ownerName/featureName。 這樣既便於知道分支覆蓋的功能，也便於找到分支的負責人。以後清理分支的時候也很方便。

開發流程

? 從 master 切出一個新分支

git checkout -b qixiu/newFeature

? 開發一些新功能，然後提交 建議較多頻次的提交代碼到本地倉庫，以便能夠更靈活的保存或撤銷修改。 此外為了保證提交日誌的清晰，建議備註清楚的註釋。

git status
git add files // 挑選需要提交的文件，或者全部提交
git commit -m ‘提交備註‘
git push origin qixiu/newFeature

? 如果功能開發完成，可以發起一個CodeReview流程 ? 如果代碼測試通過，合並到 master，然後準備上線

// 冗余版 合並到 master
git checkout master 
git pull -r origin master
git checkout qixiu/newFeature
git rebase master // 處理沖突
git checkout master
git merge qixiu/newFeature
git push origin master

// 精簡版 合並到 master
git checkout qixiu/newFeature
git pull -r origin master // 將master的代碼更新下來，並且rebase處理沖突
git push origin master // 將本地代碼更新到遠端

有幾點需要註意： 不要在master合並代碼，保證master的可用性很重要。 確保在正確的分支執行正確的操作。 無論是處理沖突還是更新遠端代碼，請保有敬畏之心。

到此，一個正常的基於功能分支的開發流程就完成了。接下來看看另外一個開發流程。

GitFlow 開發流程

GitFlow 比前文講的基於功能分支的開發流程要復雜得多，它更適合大型的復雜項目。 它圍繞項目發布流程定義了一個嚴格的分支模型，所有的開發流程都是圍繞這個嚴格的分支模型進行。 而這個模型約定了每個分支的角色，以及他們如何溝通。

我們先來看看 GitFlow 開發流程中幾個約定的分支，以及他們各自承擔的角色是怎麽樣的？

? Master分支：用於存放線上版本代碼，可以方便的給代碼打版本號。 ? Develop分支：用於整合 Feature 分支。 ? Feature分支：某個功能的分支，從 Develop 分支切出，並且功能完成時又合並回 Develop 分支，不直接和 Master 分支交互。 ? Release分支：通常對應一個叠代。將一個版本的功能全部合並到 Develop 分支之後，從 Develop 切出一個 Release 分支。這個分支不在追加新需求，可以完成 bug 修復、完善文檔等工作。務必記住，代碼發布後，需要將其合並到 Master 分支，同時也要合並到 Develop 分支。 ? Hotfix分支：緊急修復的分支，是唯一可以從 Master 切出的分支，一旦修復了可以合並到 Master 分支和 Develop 分支。

從每個分支的功能和約定可以看出，它流程多約束多，對於小規模應用並不適合。 當然 GitFlow 有一些輔助工具 gitflow 可以自動化的完成這些任務，對於大型項目也很有幫助。

前面講了 Git 有哪些基本操作，然後介紹了兩個主流的工作流程。 接下來我們看看 Git 有哪些特別的技巧值得一提。

Git 有哪些小技巧？

Git 操作除了基本的代碼管理功能，還有一些小技巧能夠讓你眼前一亮。

git reflog，查看操作記錄

這個我一定要放在第一個介紹，因為它曾經數次解救了我的代碼

仔細看上圖，reflog 記錄了你所有的 git 命令操作，對於復原某些莫名其妙的場景或者回滾誤操作有極大的幫助。

試想一個場景：你使用 git reset --hard commitID 把本地開發代碼回滾到了一個之前的版本，而且還沒有推到遠端，怎麽才能找回丟失的代碼呢？ 你如果使用 git log 查看提交日誌，並不能找回丟棄的那些 commitID。 而 git reflog 卻詳細的記錄了你每個操作的 commitID，可以輕易的讓你復原當時的操作並且找回丟失的代碼。 當然，如果你丟失的代碼都沒有提交記錄，那麽恭喜你，你的代碼真的丟了。

壓縮提交記錄

這也是一個很實用的功能，前文提過，我們在開發中的時候盡量保持一個較高頻率的代碼提交，這樣可以避免不小心代碼丟失。但是真正合並代碼的時候，我們並不希望有太多冗余的提交記錄，而且 rebase 合並代碼的時候，會把每個 commit 都處理一下，有時候會造成冗余的工作。 所以，壓縮日誌之後不經能讓 commit 記錄非常整潔，同時也便於使用 rebase 合並代碼。

那麽，如何壓縮commit記錄呢？ ? 使用 git log 找到起始 commitID ? git reset commitID，切記不要用 --hard 參數 ? 重新 git add && git commit ? git push -f origin branchName，因為會有沖突，所以需要強制覆蓋遠端分支，請務必謹慎。 ? 合並到 master 中，然後更新遠端 master。

此外還有兩種壓縮日誌的辦法： git commit --amend：追加 commit 到上一個 commit 上。 git rebase -i：通過交互式的 rebase，提供對分支 commit 的控制，從而可以清理混亂的歷史。

從實際應用來說，三種日誌壓縮都很優秀，git reset 更簡單，git rebase -i 更細膩。

git rebase，合並代碼

前文簡單介紹了 git rebase 和 git merge 的區別，坦率講，他們各有優劣。 git rebase 能讓你的 commit 記錄非常整潔，無論是線上回滾還是 CodeReview 都更輕松；但卻是一個有隱患的操作，使用時務必謹慎。 git merge 操作更安全，同時也更簡單；但卻會增加一些冗余的 commit 記錄。

這兒簡單說說 rebase 的合並流程和註意事項吧。看下圖

有三個點需要註意： ? rebase 先找出共同的祖先節點 ? 從祖先節點把 pay 分支的提交記錄摘下來，然後 rebase 到 master 分支 ? rebase 之後的 commitID 其實已經發生了變化 尤其是第三點，經常會讓人誤操作，所以務必註意。

試想一下，開發過程中，如果我們頻繁的 rebase master 分支，會有什麽後果呢？

當你不斷 rebase master 的時候，其實你本地的 d 都變成了 d` ，再要和遠端 pay 分支保持一致，你的本地分支 commit 記錄已經不堪入目了。

另外要註意，絕不要在公共的分支上使用 rebase！！！

所以，為了安全，團隊可以考慮采用 merge。

pull request，方便CodeReview

Git 不僅提供了代碼托管以及代碼開發的幫助，還提供了代碼審核類似的功能。 當我們在功能分支開發完成之後，可以發起一個 pull request 請求，選擇需要對比的兩個分支

它會創建一個 pull request，制定相關人員來對代碼進行 review。 通常情況下，團隊應該鼓勵交叉 review，涉及到公共代碼的時候，一定要讓相關人 review。

git hook，Git 的生命周期

這個大多數人應該都，聽說過，git操作有它自身的生命周期，在不同的生命周期，我們可以做一些自動化的事情。

舉兩個簡單的例子： ? pre-commit的時候我們可以做 eslint ? post-commit的時候，我們可以做利用 jenkins 類似的工具做持續集成

當然還有更多的聲明周期，具體可以參考 Git 鉤子

git submodule && git subtree，管理第三方模塊

這兩個命令通常用來管理公用的第三方模塊。比如一些通用的底層邏輯、中間件、還有一些可能會頻繁變化的通用業務組件。 當然，兩者還是有區別的。 git submodule 主要用來管理一些單向更新的公共模塊或底層邏輯。 git subtree 對於部分需要雙向更新的可復用邏輯來說，特別適合管理。比如一些需要復用的業務組件代碼。在我之前的實踐中，我也曾用subtree來管理構建系統邏輯。

git alias，簡化 Git 命令

我們可以通過配置 git alias 來簡化需要輸入的 Git 命令。 比如前文的 git subtree 需要輸入很長的 Git 命令，我們可以配置 .git/config 文件來解決。

// git stpull appfe demo/xxx
// git stpush appfe demo/xxx
[alias]
    stpull = !git subtree pull --prefix=$1 appfe $2         && :
    stpush = !git subtree pull --prefix=$1 appfe $2         && git subtree split --rejoin --prefix=$1 $2         && git subtree push --prefix=$1 appfe $2         && :

總結說點啥？

該文首先介紹了 Git 常規操作 ? 包括克隆代碼、操作 commit、操作分支等。其實 Git 常規操作的命令並不多，請看第一部分的簡單總結。

其次介紹了 Git 開發流程 ? 該部分主要介紹了兩種主流的開發模式：比較輕量的 基於功能分支的開發流程 和適合復雜項目的 GitFlow 開發流程 ，兩種模式各有使用的場景，對於常規使用，前者就已經足夠了。

最後介紹了一些 Git 實用技巧 ? 主要包括：reflog 操作，壓縮日誌，rebase 的註意事項，利用 pull request 做 codeReview，利用 git hook 做一些自動化工作等。

相關閱讀

Git超實用總結