[譯] 我沒法想象沒有 Git 別名的的場景

• 原文地址：Git aliases I can't live without
• 原文做者：MICHAŁ KONARSKI
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Starrier
• 校對者：TrWestdoor，CoolRice

我沒法想象沒有 Git 別名的的場景

你們看到個人 Git 工做流時，老是充滿了驚訝與好奇：

個人 Git 工做流

我對別名的熱愛，始於我初次下載 zsh 和它的 oh-my-zsh 套件。它包含大量針對不一樣命令行程序的預約義別名和幫助函數。我馬上便喜歡上了這種取代常規的那些很長的參數化調用的輸入概念。由於我最常使用的工具是 Git，因此它是我開始別名變革的首選目標。幾年以後的如今，我沒法想象使用 Git 自帶的那些原始 git 命令。

固然，Git 自己就擁有完美的別名自定義系統。對我來講，我只是不喜歡 git 和別名之間的空白。Shell 別名也很靈活而且還能夠用於其餘命令行，例如 docker。

下面你會找到我使用最多的別名列表。其中一些直接源自於 oh-my-zsh，其餘一些是我本身創造的。我喜歡大家至少能夠找到一些有用的！若是你想親自嘗試全部的這些方法，能夠從個人倉庫下載。

1. 咱們從這個庫開始吧！

alias gcl = git clone

這可能不是 Git 用戶最常使用的命令，但我我的但願儘快讓大家掌握這些使人生畏的 GitHub 項目，就像我所但願的那樣。

2. 從遠程倉庫獲取分支最新動態

alias gf = git fetch

我一般使用 fetch 來獲取遠程倉庫的最新更改，由於它不會以任何形式影響工做目錄的 HEAD。以後我會使用其餘命令來顯式修改本地文件。

3. 咱們查看一下其餘分支！

alias gco = git checkout

對於平常開發來講，這無疑是最有用的命令之一。我決定寫這篇文章的緣由之一就是發現你們每次在他們想要切換分支時，仍然須要使用 git checkout。

4. 回退到以前的分支狀態！

gco -

這個破折號是一個小把戲，意思是「之前的分支」。我知道嚴格意義上，它不算是別名，但它太過有用以致於不得不提。並且，我印象中沒有多少人知道它。

checkout 不是接受破折號的惟一選項 —— 你也能夠在其餘地方使用，好比 merge、cherry-pick 和 rebase。

5. 快速切換至 master 分支

alias gcm = git checkout master

若是咱們常常在一些有明肯定義的的分支之間進行切換，那麼咱們爲何不使其儘量簡單一些呢？根據你的工做流，你也能夠找出其餘類似的有用別名：gcd (develop)、gcu (uat)、gcs (stable)。

6. 我在哪？發生了什麼？

alias gst = git status

簡單明瞭。

7. 我不在乎當前工做變化，只要從源分支給我最新的狀態就行！

alias ggrh = git reset --hard origin/$(current_branch)

個人我的最愛。有多少次你製造瞭如此嚴重的混亂，以致於你只想讓暫存區和工做目錄恢復到原來的狀態？如今只剩下四個按鍵了。

請注意，這個特定的命令將當前分支重置爲來源於 origin 分支的最新提交。這正是我一般最須要的，但可能不是你須要的東西。每當我不關心本地更改時，我都會使用它，我只但願個人當前分支可以反映對應的遠程分支。你可能會說你可使用 git pull 替帶，但我只是不喜歡它會試圖合併遠程分支，而不僅是將當前分支重置爲遠程分支。

注意 current_branch 是一個自定義函數（由 oh-my-zsh 做者建立）。你能夠在這裏看到它。

8. 當前的更改是什麼？

alias gd = git diff

有一個典型示例。它只是顯示了全部的改變，但並無分階段。若是要查看已經進行的更改，請使用此版本：

alias gdc = git diff --cached

9. 讓咱們提交那些更改的文件！

alias gca = git commit -a

這會提交全部的更改文件，所以你不須要手動添加它們。可是，若是有一些還沒有提交的新文件，顯然須要顯式地說明它們：

alias ga = git add

10. 我想在先前的提交中添加一些更改！

alias gca! = git commit -a --amend

我常用它，由於我喜歡保持 Git 歷史記錄的整潔（沒有 「pull request fixs」 或者 「forgot to add this file」 類型的提交信息）。它只需簡單接受全部的更改並將他們添加到上一次提交中。

11. 我以前的分支作的太快，那麼怎麼「撤銷」一個文件？

gfr() {
    git reset @~ "$@" && git commit --amend --no-edit
}
複製代碼

這是一個函數，不是別名，乍看好像有些複雜。它獲取要「取消提交」的文件名稱，從 HEAD 提交中刪除對該文件所作的全部更改，但將其保留在工做目錄中。而後，它會準備分階段提交，也許是做爲一個獨立提交。這就是它在實踐中的工做方式：

12. 好的，準備推送！

alias ggpush = git push origin $(current_branch)

我每次想推送的時候，都會使用這個。由於它是隱式傳遞遠程分支參數，因此我能夠確保只推送一個分支，而無須在乎 push.default 設置。從 Git 2.0 開始，它會成爲默認行爲，可是別名爲我提供了額外的安全保證，以防我使用一些 Git 遺留的版本問題。

對於正常的推送，這可能並不那麼重要，但對於下一個命令來講，這很是關鍵。

13. 我已經準備推送了，並且我知道我在作什麼

alias ggpushf = git push --force-with-lease origin $(current_branch)

強制推送顯然是一個有爭議的習慣，許多人會說你永遠不該該這樣作。我贊成，但只有涉及到分享像 master 這樣的分支時纔會有問題。

正如我說起的，我喜歡保持個人 git 歷史乾淨。這有時涉及更改已經被推送的提交。這時，--force-with-lease 就會特別有用，由於當你的本地倉庫沒有更新到遠程分支的最新狀態時，它會拒絕推送。所以，它不可能拋棄別人的修改，至少不會在無心中拋棄。

在個人同事有一次錯誤地調用了 git commit -f（將 push.default 設置爲 matching）以後，我開始使用這個別名，將遠程分支部分名稱設置爲 $(current_branch)，並強制推送全部的本地分支到 origin 分支。包括一箇舊版本的 master，當他意識到發生了什麼以後，我仍然記得他眼中的恐慌。

14. 哇，推送被拒絕了！有人動了個人分支！

你試圖將你的分支推送到遠程倉庫，但獲得了一下信息：

To gitlab.com:mjkonarski/my-repo.git
 ! [rejected]        my-branch -> my-branch (non-fast-forward)
error: failed to push some refs to 'git@gitlab.com:mjkonarski/my-repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again. 
複製代碼

當多我的同時在一個分支上工做時，就會發生這種狀況。也許你的同事在你不知情的狀況下，又推送了一個修改？或者你用了兩臺電腦，同步了以前的分支？一下是一個簡單的解決方案：

alias glr = git pull --rebase

它會自動拉取最新的修改，而後將你的提交 rebase 到他們的頂部。若是你足夠幸運（而且對不一樣的文件進行了遠程修改），你甚至能夠避免解決衝突。哇，又要從新推送！

15. 我想用本身的分支來映射主分支的最新變化！

假設你有一個分支是不久以前從 master 分支建立的。你已經推送了一些改變，但同時也更新了 master 自己。如今，你但願你的分支能夠反映那些最新的提交內容。在這種狀況下，相比 merge，我更喜歡 rebase —— 你的提交歷史保持保持簡短和清晰。就像打字同樣簡單：

alias grbiom = git rebase --interactive origin/master

我常用這個命令，所以這個別名是我最開始使用的第一批命令之一。--interactive 啓用了你最愛的編輯器，並容許你快速檢查即將基於 master 提交的提交列表。你也能夠利用這個機會來 squash、reword 或者 reorder 提交。所以有許多簡單別名能夠選擇！

16. emmm，我嘗試了 rebase，但出現了嚴重的衝突！救命啊！

沒有人喜歡這些信息：

CONFLICT (content): Merge conflict in my_file.md

Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
複製代碼

有時，你可能只想停止整個進程，以後再解決衝突。以上信息是如何處理的線索，但爲何須要這麼多按鍵呢？

alias grba = git rebase --abort

咱們又安全了。當你終於鼓起勇氣再次進行合併解決這些衝突時，在 git add 以後，你只需繼續進行 rebase 輸入便可：

alias grbc = git rebase --continue

17. 請把這些變化暫時擱淺！

假設你已經作了一些改變，但尚未提交它們。如今你想快速切換到另外一個分支，並執行一些無關的工做：

alias gsta = git stash

這個提交將你的修改放在一邊，並恢復至 HEAD 的乾淨狀態。

18. 如今，開始回退！

當你完成了與你無關的工做時，你可能會快速回退你的修改：

alias gstp = git stash pop

19. 這個小提交，看起來很棒，讓咱們把它放到本身的分支上！

Git 有一個叫作 cherry-pick 的優秀功能。你可使用它來將任何現有提交添加到當前分支的頂部。它就像使用這個別名同樣簡單：

alias gcp = git cherry-pick

這固然會致使衝突，固然這也取決於你提交的內容。解決這個衝突與解決 rebase 衝突的方法徹底同樣。所以，咱們也有相似的選擇來停止以及繼續選擇分支：

alias gcpa = git cherry-pick --abort

alias gcpc = git cherry-pick --continue

---

以上列表確定沒有涵蓋全部 git 用例。我想鼓勵你把它看做是創建你本身的化名套件的良好開端。在平常工做流程中尋求可能的改進是一個好主意。

你能夠在個人 Github 倉庫看到這些別名（甚至更多）。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。