10 個技巧促使你的 Git 的技能上一個台階

譯者：Herylee，

原文出處，

譯文出處

最近，我們發布了一些教程促使你了解 Git 基礎知識和在團隊環境中使用 Git。談論的指令已經足夠幫助一個開發者在 Git 世界中生存。在這次教程中，我們嘗試如何在有效的時間內充分掌握提供的 Git 特性。

說明：文中一些指令包含指令的部分在方括弧中（如：git add -p [file_name]）。在這些案例中，你可以不用方括弧，選擇插入一些必要的數字，標識符等等，

1. Git 自動完成

如果你通過命令行運行 Git 命令，每一次通過手動敲來完成是令人煩惱的。為了幫助你做到這點，你可以使 Git 命令在幾分鐘內自動完成。

將下列腳本運行在 Unix 系統中。

cd ~ curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash

接下來，在你的 ~/.bash_profile 文件中添加下面幾行：

if [ -f ~/.git-completion.bash ]; then . ~/.git-completion.bashfi

儘管之前提到過，我仍然不能強調其重要性：如果你想充分運用 Git 的特性，你應該明確地轉變對命令行的交互！

2. 忽略 Git 文件

你是否對出現在你 Git 源中編譯文件（如 .pyc）感到疲倦？或者對添加這些文件至 Git 上忍無可忍？不用捨近求遠，這裡有一種方式可以告訴 Git 忽視特定的文件和目錄。只要創建一個名字為 .gitignore 的文件，並列出你不想讓 Git 處理的文件和文件夾。你可以使用感嘆號（!）來特殊處理。).

*.pyc*.exemy_db_config/!main.pyc

誰打亂了我的代碼？

當某些事出現問題時，責備其他人是人類的本性。如果你的產品伺服器壞掉了，很容易查明真兇 —— 只需執行下 git blame指令。這個命令會顯示每一個文件中每一行代碼的作者，提交會看到當前行的最後一次變化，同時也提交時間戳。

`git blame [file_name]`

在屏幕截圖下，你會看到這個命令就像一個巨大的源：

4. 審核源的歷史

我們已經在以前的教程中了解過 git log 的運用了，但是這裡仍然有你需要知道的三個選項。

-oneline -將每次提交展示的信息壓縮至精簡的提交哈希和提交信息中，所有的展示在一行中。

-graph -這個選項繪製了一個在輸出左側基於文本的圖形展示的歷史信息。如果你想看到每個分支的歷史信息是無用的。

-all -展示所有分支的歷史信息。

下面是這些選項的組合：

5. 永遠不要失去對 Commit 的關注

讓我們談論那些你不想提交的，最後經過了一個艱難的重置回到你之前的狀態。後面，你意識到這個過程丟失了一些其他的信息並想返回去，或者至少可以再次看下。這就是 git reflog 作用。

一個簡單的 git log 命令可以顯示最新的提交，上一次的提交，上上次的提交等等。然而，git reflog是一個被指向提交的列表。記住：這是你系統的局部，不是源的部分，不包含推送的和合併的。

如果執行 git log，我獲取的提交信息是源的一部分。

然而，當你執行硬重置時，git reflog 展示了提交信息（b1b0ee9–HEAD@{4}）是丟失的。

6. 更改一次提交文件的分段部分

基於特性的提交通常是一個好的實踐，也就是，每次提交都要展現出一個特性或修改的bug。想想如果你修復了兩個bug會發生什麼，或者添加多個特徵卻沒有提交改變。在這種情況下，你可以將這些改變放在一個簡單的提交中。但是，這裡還有一個更好的方式，將文件單獨地分段並分別提交他們。

讓我們看看你做的幾個改變至單個文件中，並想讓他們出現在分離的提交中。在這種情況下，我們可以通過添加前綴 -p 來添加文件。

git add -p [file_name]

讓我們來證明一致性。我已經添加了三個新行至 file_name，而且我僅想第一和第三行出現在提交信息中。讓我們看看 git diff 展示給我們的信息。

讓我們看看當我們添加一個前綴 -p 至 add 命令上發生了什麼。

似乎 Git 假設所有的改變都是同樣的，因此，將它們分成一個大塊。你有下列選擇：

輸入 y 分成塊

輸入 n 不分塊

輸入 e 手動編輯塊

輸入 d 退出或者進入下一個文件

輸入 s 分離塊

在我們的案例中，我們當然想將它分離成小塊，可以有選擇地添加一部分並忽略其餘的。

正如你所看到的，我們已經添加第一行和第三行的信息並忽略了第二行的信息。你可以查看源的狀態並提交。

7. 壓縮多次提交

當你提交你的代碼是為了查看和創建一個新的推送請求（在開源項目中經常出現），在接受前，你可以要求改變的你的代碼。你做出改變，僅僅是要求改變它以便下次查看。在你知道前，你可以做一些額外的提交。理想地，你可以使用 rabase 指令壓縮它們。

git rebase -i HEAD~[number_of_commits]

git rebase -i HEAD~2

要求你為新提交的準備提交信息。這個處理基本上會覆蓋你的提交歷史。

8. 保存未提交的變化

讓我們探討你正在致力於某個 bug 和特徵時，要求驗證你的工作。你當前的工作不足夠提交，並且你並不能在這個階段給出一個證明（沒有回復改變值）。在這種情況下，git stash 可以幫助你。Stash 基本上具有你所有的改變並保存它們以便你後期使用。為了保存這些變化，你需要運行以下命令：

git stash

git stash list

如果你想不保存和恢復未提交的變化，你可以應用下面的保存：

git stash apply

在最後一個截圖中，你可以看到每次保存都有個標識符，一個唯一的數字（儘管我們僅僅在這種情況下保存）。如果你想只選擇有選擇性的保存，你可以添加特殊的標識符到 apply 命令中。

git stash apply stash@{2}

9. 核對丟失的提交信息

儘管 reflog 是核對上次丟失的提交信息的一種方法，但在大量的源中，不是可行的。這就是 fsck(文件系統核對) 命令要做的。

git fsck --lost-found

在這裡，你可以看到丟失的提交信息。那你可以通過運行 git show [commit_hash] 來核對改變的提交信息，或者通過執行 git merge [commit_hash] 來回復它。

git fsck 相比 reflog 有一種優勢。讓我們看看你刪除了一個遠程的分支，然後克隆源。使用 fsck，你可以查詢和恢復刪除的遠程分支。

10. 做出最佳選擇

在之前，我保存了很多簡潔的 Git 指令。cherry-pick 指令是迄今為止我最喜歡的 Git 命令，是由於它的字面意義和它的功能！

用最簡單的術語來說，cherry-pick 是從不同的分支中選擇單個提交和將它和當前分支的合併。如果你在兩個或更多的分支中工作，你可能會注意到 bug 會出現所有的分支。如果你在其中一個分支解決了這個 bug，你可以使用 cherry pick 提交至其他分支，不干擾其他文件或提交。

讓我們想想可以運用的場景。我有兩個分支，並且我想 cherry-pick 提交 b20fd14:清理垃圾：至另外一個分支。

切換分支至我想 cherry-pick 的提交，並執行以下指令：

git cherry-pick [commit_hash]

儘管我們已經清除了 cherry-pick 的時間，但是你應該知道這個命令可能經常導致衝突，因此要慎用。

結論

以上，總結下小技巧清單，我認為可以幫你的 Git 技能達到一個新的台階。Git 是最好的，可以實現任何你想像的。因此，要總是嘗試挑戰自己使用 Git。你很有可能會學到一些新的東西！

會見作者

Shaumik Daityari.

Shaumik 是一個樂觀主義者，但是一直都是一個人。他是印度 Roorkee 理工學院的一名本科生，也是博客的創始人之一，他喜歡寫作，當他不忙時，總是保持寫作的習慣。

作者： linux零基礎學習視頻

鏈接：https://www.imooc.com/article/23774

來源：慕課網

推薦閱讀：

GitLab安裝、使用教程（Docker版）

高效開發技巧：為什麼你下載Git項目這麼慢？

教你用github page搭建一個自己的個人化博客網站

git入門，先學會這幾個姿勢！

Github上Python超越Java，人工智慧程序員大熱