第 30 天:分享工作中幾個好用的 Git 操作技巧
Last updated
Last updated
終於來到了最後一天,這篇文章將分享幾個好用的 Git 操作技巧,或許可以節省你不少 Git 版控過程的時間。
我們在使用 GitHub 的時候,由於預設使用 HTTPS 通訊協定取得 Git 儲存庫,例如:https://github.com/doggy8088/frontend-tools.git
。但事實上你可以改用 SSH 選擇當成取得 Git 遠端儲存庫的網址,如下圖示:
使用 HTTPS 通訊協定來存取 GitHub 上的遠端儲存庫,由於無法記憶帳號密碼,所以每次執行遠端儲存庫的指令一定都會被要求輸入帳號、密碼。但改用 SSH 的話,就可以透過預先定義好的金鑰來進行身分驗證。
在第一次使用 GitHub for Windows 工具的時候,如果你有照著步驟登入與設定,這套工具會預設幫你產生一對金鑰,然後該工具會自動上傳到 GitHub 的 SSH Key 專區,讓你日後不用再輸入帳號密碼,就能順利的操作 GitHub 上的遠端儲存庫。
這一對金鑰,預設就放在 %USERPROFILE%\.ssh
資料夾下,如果你的 Windows 登入使用者名稱為 Will
的話,這個路徑就位於 C:\Users\Will\.ssh
目錄下。這對金鑰的檔名分別是 github_rsa
(私鑰) 與 github_rsa.pub
(公鑰),如下圖示:
也因為這一對金鑰的存在,所以你在 Git Shell 底下操作 Git 指令,所有針對遠端儲存庫上的操作,都不需要再次輸入帳號密碼。
事實上,不用輸入密碼的原因是「GitHub for Windows 工具已經把 SSH 金鑰上傳到 GitHub 網站了」,設定的網址在 https://github.com/settings/ssh
,我們可以從以下圖示看出設定的位址:
不過,如果你希望在「命令提示字元」(非 Windows Powershell 執行環境)下也可以不用輸入帳號密碼驗證,那麼你可以嘗試將 %USERPROFILE%\.ssh
資料夾下的兩個檔案分別把 github_rsa
複製一份改名成 id_rsa
,然後把 github_rsa.pub
複製一份改名成 id_rsa.pub
,即可完成設定!完成後如下圖示:
這樣就可以大功告成。
不過,如果你之前從 GitHub 複製回來的版本庫是用 HTTPS 通訊協定的話,那麼你還必須將這個遠端 URL 修改成 ssh 的格式。例如我們現有的 remote URL 如下:
我們可以用 git remote set-url origin git@github.com:doggy8088/frontend-tools.git
來將現有的遠端 URL 改成 SSH 的通訊協定,請看一下執行過程:
如此一來,就可以不再需要驗證帳號密碼了。
由於 GitHub for Windows 幫我們建立好一個現成的金鑰,如果你要直接沿用,可以透過以下步驟產生 GitHub 與 Bitbucket 都能支援的 SSH 金鑰格式:
如果你有安裝 SourceTree 的話,將會在以下路徑找到 puttygen.exe
工具,並請直接開啟程式:
路徑:C:\Program Files (x86)\Atlassian\SourceTree\tools\putty
接著載入 %USERPROFILE%\.ssh\github_rsa
私密金鑰檔案,並複製產生後的一串亂碼,這就是 SSH 金鑰中的公鑰:
※ 不過,如果你已經有 github_rsa.pub
這個檔案的話,直接用 Notepad 開啟這個檔案,也可以直接拿來當成公鑰的內容。
這個 SSH 公鑰的內容格式大致如下:
接著進入 Bitbucket 首頁,並找到 SSH Key 頁面,並按下 Add Key 以新增金鑰:
輸入一個好記名稱與公鑰內容後,就大功告成,從今以後連接 Bitbucket 也不用再輸入帳號、密碼了。
git rebase
變動如果單純地用 git merge
合併一個檔案,要還原合併很簡單,直接打 git reset --hard ORIG_HEAD
即可還原本次合併的變更。但是 git rebase
怎麼辦?因為 git rebase
會將版本線圖改變,而且分支的結構也會發生變化,感覺上好像很難做還原動作,但其實非常簡單。
我用一張圖來解釋還原的過程:
先知道你在 Rebase 之前,是落於哪個版本。
再查出你要從哪個版本開始 Rebase
然後真正執行 Rebase 動作
不管做了哪些動作,你再執行一次 git reflog
就可以看出 Rebase 真正做了幾件事
若要還原 Rebase 的版本,只要找到 Rebase 之前的版本,就可以透過 git reset --hard
來還原
由於我們透過 git clone
的時候,就可以抓回完整的版本紀錄,這代表我們可以隨時在本地儲存庫統計版本資訊。
例如我們想取得版本庫中所有人的 commit 次數統計,可以輸入 git shortlog -sne
即可詳細列出每個人的 commit 次數,而且加上 -n
參數還可以按照 commit 數量進行降冪排序:
也可以利用 git shortlog
顯示出每個人最近 commit 過的歷史紀錄。
你也可以利用 GitHub 上 Graph 頁面提供的統計資訊:
這裡主要提供六種報表:
Contributors (本專案貢獻者的活躍程度)
Commit Activity (每一天的 commit 活動數量)
Code Frequency (原始碼異動服務,可看出每天新增與刪除的程式碼行數)
Punchcard (每一天的 commit 數量,用打卡的方式來顯示) (類似上下班打卡的那種卡片)
Network (pull request 與 merge 的圖形表示)
Members (所有 fork 此專案的 github 成員)
點進去之後,還可以繼續往下鑽(Drill-Down),查看更細的統計報表:
我們在 Git 工作目錄中,通常會產生一些不必要的檔案,而這些檔案通常都會透過 .gitignore
檔案,讓 Git 自動忽略這些檔案。如果你今天想要把這些額外的檔案都給刪除掉,可以透過 git clean -f
強迫刪除這些檔案。
不過,執行之前,還是建議用 git clean -n
看一下,這個指令會列出他「預計」會刪除那些檔案,等你確認過後在執行 git clean -f
刪除即可檔案。
如果你將「本地分支」透過 git push origin FixForCRLF
指令建立起「遠端分支」,也代表在遠端會被建立一個名為 FixForCRLF
的分支,如果你想在本地下指令刪除遠端追蹤分支,可以輸入以下指令 (在遠端分支前面加上個 :
而已):
另一個同樣目的的指令用法如下,指令看起來較為直覺些:
※ 不過使用時要注意,如果有人下載過這個遠端分支的話,他就再也無法透過 git push
把變更推送上來了。
替原始碼做版控,最有效的就是每個檔案的每一行都可以進行詳細追蹤,今天如果程式發生異常,且找到哪一行出錯時,就可以透過 git blame
指令,幫你找出真正改壞程式的兇手,並且去看他為什麼會改壞。
用法如下:
例如:
一些小技巧,需要的時候就會用的到。
短短 30 天,說長不長、說短不短,但我為了寫這個系列文章,還真的是累翻了。剛我把我的文章原稿放進 Word 統計,這才驚覺我寫了十幾萬字 (不含程式碼),這真是太神奇了,傑克!
如同我之前講過的,雖然市面上 Git 的 GUI 工具好幾套,但想要有效率且正確的使用這些 Git 工具,先建立起完整的 Git 基本觀念非常重要,否則只會一直鬼打牆而已。
Git 博大精深,短短 30 天著實無法完整交代所有細節,但工作上會用到的觀念與工具都講到,如果認真看的話,相信對大家在工作上會有幫助。