工作中如何優(yōu)雅的使用 Git

前言

在本系列的前兩篇博文中，筆者對 Git 以及 Git flow 進行了大致的介紹，相信各位讀者已經(jīng)對 Git 有了大致的了解。但是，在我們的日常工作中使用 Git 時常會遇到的各種突發(fā)狀況，那么我們應該怎么合理的應對這些狀況呢？俗話說，無規(guī)矩不成方圓，在團隊協(xié)作中，如何規(guī)范 Git Commit 呢？本文將針對以上問題展開討論，探討一下在日常工作中，我們應該如何優(yōu)雅的使用 Git？

你可能會忽略的 Git 提交規(guī)范

無規(guī)矩不成方圓，編程也一樣。如果在團隊協(xié)作中，大家都張揚個性，那么代碼將會是一團糟，好好的項目就被糟踐了。不管是開發(fā)還是日后維護，都將是災難。對于 Git Commit 同樣如此，統(tǒng)一 Git Commit 規(guī)范可以方便管理團隊代碼，方便后續(xù)進行 code review 以及生成 change log；統(tǒng)一 Git Commit 規(guī)范容易理解提交的信息。

分支規(guī)范

根據(jù) Git flow 工作流分支模型將我們開發(fā)分支規(guī)范為五大分支：

• Master 分支 - 生產(chǎn)分支：最為穩(wěn)定功能比較完整的隨時可發(fā)布的代碼，即代碼開發(fā)完成，經(jīng)過測試，沒有明顯的 bug，才能合并到 master 中。

• Develop 分支 - 開發(fā)分支：用作平時開發(fā)的主分支，并一直存在，永遠是功能最新最全的分支，所有的 feature、release 分支都是從 develop 分支上拉的。

• Feature 分支 - 功能分支：這個分支主要是用來開發(fā)新的功能，一旦開發(fā)完成，通過測試沒問題，我們合并回 develop 分支進入下一個 release。

• Release 分支 - 發(fā)布分支：用于發(fā)布準備的專門分支。當開發(fā)進行到一定程度，或者說快到了既定的發(fā)布日，可以發(fā)布時，建立一個 release 分支并指定版本號（可以在 finish 的時候添加）。開發(fā)人員可以對 release 分支上的代碼進行集中測試和修改 bug。全部完成經(jīng)過測試沒有問題后，將 release 分支上的代碼合并到 master 分支和 develop 分支。

• Hotfix 分支 - 熱修復分支：用于修復線上代碼的 bug。從 master 分支上拉，完成 hotfix 后，打上 tag 我們合并回 master 和 develop 分支。

標簽規(guī)范

采用三段式: v版本. 里程碑. 序號，例如 v1.2.1

• 項目結構發(fā)生重大修改，增加第一個數(shù)字

• 發(fā)布新的功能，增加第二個數(shù)字

• 修復項目中的 bug，修改第三個數(shù)字

Git Commit 信息規(guī)范

目前一般采用 Angular 的提交信息規(guī)范：信息分為 Header、Body、Footer 三部分

例子：

refactor: Restructure SQLRecognizer and UndoExecutor (#1883)

Header

Header 信息分為三部分 type(scope): subject

type（必須），用于說明 Git 提交信息的類別，有以下幾個分類

scope（可選），用于說明 commit 的影響范圍，比如數(shù)據(jù)層、控制層、視圖層等等，視項目不同而不同。

subject（必須），commit 的信息主題，盡量言簡意賅，說明提交代碼的主要變化。

Body

對本次提交的詳細描述。

Footer

• 不兼容變動（需要說明變動信息）

• 關閉issue（需要輸入issue信息）

使用 Git 時常會遇到的各種突發(fā)狀況

git stash

【1】場景重現(xiàn) one：當正在 feature 分支上開發(fā)某個新功能，這時項目中出現(xiàn)一個 bug，需要緊急修復，但是正在開發(fā)的內容只是完成一半，還不想提交，這時可以用 git stash 命令將修改的內容保存至堆棧區(qū)，然后順利切換到 hotfix 分支進行 bug 修復，修復完成后，再次切回到 feature 分支，從堆棧中恢復剛剛保存的內容。

【2】場景重現(xiàn) two：由于疏忽，本應該在 feature 分支開發(fā)的內容，卻在 develop 上進行了開發(fā)，需要重新切回到 feature 分支上進行開發(fā)，可以用 git stash 將內容保存至堆棧中，切回到 feature 分支后，再次恢復內容即可。

# 1. 創(chuàng)建 feature 分支
$ git flow feature start some-feature

# 2.在 feature 分支上開發(fā)某個新功能
...

# 3. git stash會把所有未提交的修改（包括暫存的和非暫存的）都保存起來，用于后續(xù)恢復當前工作目錄，當前的工作目錄就干凈了。
$ git stash save "feat: add user (#1983)" 

# 4. 創(chuàng)建 hotfix 分支
$ git flow hotfix start 0.1.1

# 5. 在 hotfix 分支上進行 bug 修復
...

# 6. 完成 bug 修復，提交 hotfix 分支
$ git flow hotfix finish --no-ff 0.1.1

# 7. 切換到 feature 分支
$ git checkout some-feature

# 8. 恢復工作進度到工作區(qū)，此命令的 stash@{num} 是可選項，在多個工作進度中可以選擇恢復，不帶此項則默認恢復最近的一次進度相當于 git stash pop stash@{0}
$ git stash pop stash@{num}

git stash 常用命令指南

# 保存，save為可選項，message為本次保存的注釋
$ git stash [save message]

# 所有保存的記錄列表
$ git stash list

# 恢復，num是可選項，通過git stash list可查看具體值。只能恢復一次
$ git stash pop stash@{num}

# 恢復，num是可選項，通過git stash list可查看具體值?？苫貜投啻?/span>
$ git stash apply stash@{num}

# 刪除某個保存，num是可選項，通過git stash list可查看具體值
$ git stash drop stash@{num}

# 查看堆棧中最新保存的 stash 和當前目錄的差異，num是可選項，通過git stash list可查看具體值
$ git stash show stash@{num}

# 刪除所有保存
$ git stash clear

git rebase

不知怎么，git rebase 命令被賦予了一個神奇的污毒聲譽，初學者應該遠離它，但它實際上可以讓開發(fā)團隊在使用時更加輕松。

Rebase 的黃金法則：git rebase 的黃金法則是永遠不要在公共分支上使用它。

【1】場景重現(xiàn) one：當你在功能分支上開發(fā)新 feature 時，然后另一個團隊成員在 master 分支提交了新的 commits，這會發(fā)生什么？這會導致分叉的歷史記錄，對于這個問題，使用 Git 作為協(xié)作工具的任何人來說都應該很熟悉?，F(xiàn)在，假設在 master 分支上的新提交與你正在開發(fā)的 feature 相關。需要將新提交合并到你的 feature 分支中，你可以有兩個選擇：merge 或者 rebase。

Merge 方式：最簡單的方式是通過 git merge 命令將 master 分支合并到 feature 分支中

$ git checkout feature
$ git merge master

# 或者將其濃縮為一行命令
$ git merge feature master

這會在 feature 分支中創(chuàng)建一個新的 merge commit，它將兩個分支的歷史聯(lián)系在一起。使用 merge 是很好的方式，因為它是一種 非破壞性的 操作，現(xiàn)有分支不會以任何方式被更改；另一方面，這也意味著 feature 分支每次需要合并上游更改時，它都將產(chǎn)生一個額外的合并提交。如果master 提交非?；钴S，這可能會嚴重污染你的 feature 分支歷史記錄。盡管可以使用高級選項 git log 緩解此問題，但它可能使其他開發(fā)人員難以理解項目的歷史記錄。

Rebase 方式：作為 merge 的替代方法，你可以使用以下命令將 master 分支合并到 feature分支上

$ git checkout feature
$ git rebase master

# 或者將其濃縮為一行命令
$ git rebase master feature

這會將整個 feature 分支移動到 master 分支的頂端，從而有效地整合了所有 master 分支上的提交。但是，與 merge 提交方式不同，rebase 通過為原始分支中的每個提交創(chuàng)建全新的 commits 來 重寫項目歷史記錄。

rebase 的主要好處是可以獲得更清晰的項目歷史。首先，它消除了 git merge 所需的不必要的合并提交；其次，正如你在上圖中所看到的，rebase 會產(chǎn)生完美線性的項目歷史記錄，你可以在 feature 分支上沒有任何分叉的情況下一直追尋到項目的初始提交。這樣可以通過命令 git log，git bisect 和 gitk 更容易導航查看項目。

【2】場景重現(xiàn) two：當你在功能分支上開發(fā)新 feature 時，多次提交了記錄，這時，想要在在合并 feature 分支到 master 之前清理其雜亂的歷史記錄。

交互式 rebase 使你有機會在將 commits 移動到新分支時更改這些 commits。這比自動 rebase 更強大，因為它提供了對分支提交歷史的完全控制。

要使用交互式 rebase，需要使用 git rebase 和 -i 選項：

$ git checkout feature
$ git rebase -i master

這將打開一個文本編輯器，列出即將移動的所有提交：

pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

此列表準確定義了執(zhí)行 rebase 后分支的外觀。通過更改 pick命令或重新排序條目，你可以使分支的歷史記錄看起來像你想要的任何內容。例如，如果第二次提交 fix 了第一次提交中的一個小問題，您可以使用以下 fixup 命令將它們濃縮為一個提交：

pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

保存并關閉文件時，Git將根據(jù)您的指示執(zhí)行 rebase，從而產(chǎn)生如下所示的項目歷史記錄：

消除這種無意義的提交使你的功能歷史更容易理解。這是 git merge 根本無法做到的事情。至于 commits 條目前的 pick（ 保留該 commit ）、fixup（ 將該 commit 和前一個 commit 合并，但我不要保留該提交的注釋信息 ）、squash（ 將該 commit 和前一個 commit 合并 ） 等命令，在 git 目錄執(zhí)行 git rebase -i 即可查看到，大家按需重排或合并提交即可，注釋說明非常清晰，在此不做過多說明。

git cherry-pick

git cherry-pick 可以理解為” 挑揀” 提交，它會獲取某一個分支的單筆提交，并作為一個新的提交引入到你當前分支上。當我們需要在本地合入其他分支的提交時，如果我們不想對整個分支進行合并，而是只想將某一次提交合入到本地當前分支上，那么就要使用 git cherry-pick 了。

【1】場景重現(xiàn) one：當正在 feature 分支上開發(fā)某個新功能，并且進行了多個提交。這時，你切到另外一個 feature 分支，想把之前 feature 分支上的某個提交復制過來，怎么辦？這時候，神奇的 git cherry-pick 就閃亮的登場了。

$ git cherry-pick c2 c4

git reset

git reset 通過把分支記錄回退幾個提交記錄來實現(xiàn)撤銷改動。你可以將這想象成“改寫歷史”。git reset 向上移動分支，原來指向的提交記錄就跟從來沒有提交過一樣。git reset是指將 HEAD 指針指到指定提交，歷史記錄中不會出現(xiàn)放棄的提交記錄。

【1】場景重現(xiàn) one：有時候，我們用 Git 的時候有可能 commit 提交代碼后，發(fā)現(xiàn)這一次 commit 的內容是有錯誤的，那么有兩種處理方法：1、修改錯誤內容，再次 commit 一次；2、使用 git reset 命令撤銷這一次錯誤的 commit。第一種方法比較直接，但會多次一次 commit 記錄。而我個人更傾向第二種方法，錯誤的 commit 沒必要保留下來。那么今天來說一下 git reset。

Git reset 命令有三個主要選項：git reset –soft; git reset –mixed; git reset –hard;

• git reset –soft：軟合并 - 保留工作目錄，并把重置 HEAD 所帶來的新的差異放進暫存區(qū)。重置位置的同時，保留 working Tree 工作目錄和 index 暫存區(qū)的內容，只讓 repository 中的內容和 reset 目標節(jié)點保持一致，因此原節(jié)點和 reset 節(jié)點之間的【差異變更集】會放入 index 暫存區(qū)中 (Staged files)。所以效果看起來就是工作目錄的內容不變，暫存區(qū)原有的內容也不變，只是原節(jié)點和 Reset 節(jié)點之間的所有差異都會放到暫存區(qū)中。

• git reset –mixed：混合合并（默認） - 保留工作目錄， 并清空暫存區(qū)。重置位置的同時，只保留 Working Tree 工作目錄的內容，但會將 Index 暫存區(qū) 和 Repository 中的內容更改和 reset 目標節(jié)點一致，因此原節(jié)點和 Reset 節(jié)點之間的【差異變更集】會放入 Working Tree 工作目錄中。所以效果看起來就是原節(jié)點和 Reset 節(jié)點之間的所有差異都會放到工作目錄中。

• git reset –hard：強行合并 - 重置 stage 區(qū)和工作目錄。重置位置的同時，直接將 working Tree 工作目錄、 index 暫存區(qū)及 repository 都重置成目標 Reset 節(jié)點的內容， 所以效果看起來等同于清空暫存區(qū)和工作區(qū)。

git revert

git revert 撤銷一個提交的同時會創(chuàng)建一個新的提交。這是一個安全的方法，因為它不會重寫提交歷史。

【1】場景重現(xiàn) one：改完代碼匆忙提交，上線發(fā)現(xiàn)有問題，怎么辦？趕緊回滾。改完代碼測試也沒有問題，但是上線發(fā)現(xiàn)你的修改影響了之前運行正常的代碼報錯，必須回滾。

# 撤銷指定 commit 到當前 HEAD 之間所有的變化
$ git revert [commit]..HEAD

# 撤銷指定 commit 到當前 HEAD 之間所有的變化 [不自動生成多個新的 commit，而是用一個 commit 完成]
$ git revert -n [commit]..HEAD

git revert 用于反轉提交，用一個新提交來撤銷某次提交，執(zhí)行 git revert 命令時要求工作樹必須是干凈的。git revert 之后你再 git push 既可以把線上的代碼更新。git revert 是放棄指定提交的修改，但是會生成一次新的提交，需要填寫提交注釋，以前的歷史記錄都在。

強烈推薦

如果你不能很好的應用 Git，那么這里為你提供一個非常棒的 Git 在線練習工具 Learn Git Branching。

參考博文

[1]. Oh Shit, Git!?!

source: https://morning-pro.github.io/archives/97ab96a0.html

喜歡，在看