編程git

『壹』 漫話：如何給女朋友解釋什麼是Git和GitHub

來自：漫話編程

周末，我正在家裡看《最強大腦》，女朋友在一旁刷手機，相安無事。誰知道，剛過了沒多久，她突然問我：

版本控制

想要介紹什麼是GitHub，就要介紹下什麼是Git，想要介紹什麼是Git，那就不得不提版本控制。

我們知道，如果多台計算機在同一個區域網中，是可以進行區域網文件共享的。共享者可以通過設置把自己文件共享給他人進行閱讀和修改。

對於同一份共享文件，如果又多個人需要修改的話會發生什麼事情呢？假設現在有三個人，A分享了文件夾mhcoding，其中包含了三個文件mhcoding1.png，mhcoding2.png，mhcoding3.png，B和C需要對這份文件進行修改。

B和C分別把mhcoding文件夾拷貝到自己的電腦上，然後進行修改，改完之後需要再把自己修改上傳上去。B先改完了之後把自己的文件上傳上去，覆蓋了A的分享。之後C也改完了，也把自己的改動上傳上去。這樣，C就會把B的修改覆蓋掉。

為了上述這種問題，就需要通過一種方式來在C想要上傳文件的時候來提醒他，告訴他需要考慮到B已經改過文件的事情。

比較好的方式就是通過版本控制。

如果使用了版本控制系統，每一個團隊成員都可以在任何時間對任何文件毫無顧慮的進行修改，版本控制系統可以提醒我們文件修改沖突，甚至可以幫我們自動把多個人的改動合並到一起。

有了版本控制，我們還可以回溯查看以前某一個版本中具體文件的內容，還可以查看某一次改動的變更內容。非常適合團隊協作。

版本控制的方式

本地版本控制系統

許多人習慣用復制整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。這么做唯一的好處就是簡單。不過壞處也不少：有時候會混淆所在的工作目錄，一旦弄錯文件丟了數據就沒法撤銷恢復。

為了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是採用某種簡單的資料庫來記錄文件的歷次更新差異。

集中化的版本控制系統

接下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？於是，集中化的版本控制系統應運而生。

這類系統，都有一個單一的集中管理的伺服器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這台伺服器，取出最新的文件或者提交更新。

這種做法帶來了許多好處，特別是相較於老式的本地版本來說。現在，每個人都可以在一定程度上看到項目中的其他人正在做些什麼。而管理員也可以輕松掌控每個開發者的許可權，並且管理起來也輕松容易的多。

分布式版本控制系統

集中化最顯而易見的缺點是中央伺服器的單點問題。如果中央伺服器宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。

要是中央伺服器的磁碟發生故障，碰巧沒做備份，或者備份不夠及時，就會有丟失數據的風險。

於是分布式版本控制系統面世了。在這類系統中，客戶端並不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。這么一來，任何一處協同工作用的伺服器發生故障，事後都可以用任何一個鏡像出來的本地倉庫恢復。因為每一次的提取操作，實際上都是一次對代碼倉庫的完整備份。

Git

git其實就是一款我們前面介紹的分布式版本控制軟體，Git具有以下特點：

程序員是比較典型的需要團隊協作的職業，大多數情況下，都是需要多個程序員同時開發同一個項目的，就好像多個程序員要同時修改一份word文檔一樣。所以，Git是很多程序員的必備工具。

GitHub

GitHub是一個面向開源及私有軟體項目的託管平台，因為只支持git 作為唯一的版本庫格式進行託管，故名GitHub。

所謂託管平台，也就是說他可以用於存放文件。只不過上面的文件都是可以公開被訪問到的。

GitHub是通過Git進行版本控制的軟體源代碼託管服務，並且，GitHub還引入了一些社交屬性。號稱是世界上最大的程序員（同性）交友網站。

GitHub上那些奇葩"項目"

Dress - 女裝大佬聚集地

有129名貢獻者在這個名為Dress的項目里集結，上傳了數千張女裝照，收獲了8000餘顆星。

你敢相信這是個碼農？

地址：https://github.com/komeiji-satori/Dress

Thanos - 滅霸命令

Thanos.sh是一個開源的個滅霸命令，可隨機刪除電腦上一半文件。

地址：https://github.com/hotvulcan/Thanos.sh

nocode - 一行代碼都沒有

這是一個Issue比項目更精彩的項目，項目中一行代碼都沒有，Issue中各種裝逼。

想問下，Star這個項目的2.7萬人是有多無聊？？？

programmer-job-blacklist 碼農找工作黑名單

hangzhou_house_knowledge 杭州買房攻略

howmanypeoplearearound 通過 Wi-Fi 信號估計附近有多少人

『貳』 [編程工具]Git 的 Go 語言實現 go-git

go-git 是一個 Go 語言實現的高度可擴展的 Git 實現庫。可以使用友好的 API 來管理 Git 的倉庫。支持不同類型的存儲，包括內存文件系統，也可以通過介面 Storer實現對存儲的擴展。

該項目從 2015 年開始開發。項目旨在兼容 git ，所有的操作實現與git完全一樣。兩者的兼容比較請閱讀 compatibility documentation.

基本示例

一個實現 git clone 的最基本示例：

輸出結果：

實現內存存儲的示例

將 git 倉庫克隆到內存中，並列印 HEAD 的 歷史 記錄，類似 git log ：

輸出結果：

『叄』 Git 不要只會 pull 和 push，試試這 5 條提高效率的命令

使用 Git 作為代碼版本管理，早已是現在開發工程師必備的技能。可大多數工程師還是只會最基本的保存、拉取、推送，遇到一些commit管理的問題就束手無策，或者用一些不優雅的方式解決。

本文分享我在開發工作中實踐過的實用命令。這些都能夠大大提高工作效率，還能解決不少疑難場景。下面會介紹命令，列出應用場景，手摸手教學使用，讓同學們看完即學會。

官方解釋：當您想記錄工作目錄和索引的當前狀態，但又想返回一個干凈的工作目錄時，請使用git stash。該命令將保存本地修改，並恢復工作目錄以匹配頭部提交。

stash 命令能夠將還未 commit 的代碼存起來，讓你的工作目錄變得干凈。

我猜你心裡一定在想：為什麼要變干凈？

應用場景：某一天你正在 feature 分支開發新需求，突然產品經理跑過來說線上有bug，必須馬上修復。而此時你的功能開發到一半，於是你急忙想切到 master 分支，然後你就會看到以下報錯：

因為當前有文件更改了，需要提交commit保持工作區干凈才能切分支。由於情況緊急，你只有急忙 commit 上去，commit 信息也隨便寫了個「暫存代碼」，於是該分支提交記錄就留了一條黑 歷史 …(真人真事，看過這種提交)

如果你學會 stash，就不用那麼狼狽了。你只需要：

就這么簡單，代碼就被存起來了。

當你修復完線上問題，切回 feature 分支，想恢復代碼也只需要：

當有多條 stash，可以指定操作stash，首先使用stash list 列出所有記錄：

應用第二條記錄：

pop，drop 同理。

stash 代碼

填寫備注內容，也可以不填直接Enter

在STASHES菜單中可以看到保存的stash

先點擊stash記錄旁的小箭頭，再點擊 apply 或者 pop 都可恢復 stash

完全不接觸索引文件或工作樹（但會像所有模式一樣，將頭部重置為）。這使您的所有更改的文件更改為「要提交的更改」。

回退你已提交的 commit，並將 commit 的修改內容放回到暫存區。

一般我們在使用 reset 命令時， git reset --hard 會被提及的比較多，它能讓 commit 記錄強制回溯到某一個節點。而 git reset --soft 的作用正如其名， --soft (柔軟的) 除了回溯節點外，還會保留節點的修改內容。

回溯節點，為什麼要保留修改內容？

應用場景1：有時候手滑不小心把不該提交的內容 commit 了，這時想改回來，只能再 commit 一次，又多一條「黑 歷史 」。

應用場景2：規范些的團隊，一般對於 commit 的內容要求職責明確，顆粒度要細，便於後續出現問題排查。本來屬於兩塊不同功能的修改，一起 commit 上去，這種就屬於不規范。這次恰好又手滑了，一次性 commit 上去。

學會 reset --soft 之後，你只需要：

reset --soft 相當於後悔葯，給你重新改過的機會。對於上面的場景，就可以再次修改重新提交，保持干凈的 commit 記錄。

以上說的是還未 push 的commit。對於已經 push 的 commit，也可以使用該命令，不過再次 push 時，由於遠程分支和本地分支有差異，需要強制推送 git push -f 來覆蓋被 reset 的 commit。

還有一點需要注意，在 reset --soft 指定 commit 號時，會將該 commit 到最近一次 commit 的所有修改內容全部恢復，而不是只針對該 commit。

舉個例子：

commit 記錄有 c、b、a。

reset 到 a。

此時的 HEAD 到了 a，而 b、c 的修改內容都回到了暫存區。

給定一個或多個現有提交，應用每個提交引入的更改，為每個提交記錄一個新的提交。這需要您的工作樹清潔（沒有從頭提交的修改）。

將已經提交的 commit，復制出新的 commit 應用到分支里

commit 都提交了，為什麼還要復制新的出來？

應用場景1：有時候版本的一些優化需求開發到一半，可能其中某一個開發完的需求要臨時上，或者某些原因導致待開發的需求卡住了已開發完成的需求上線。這時候就需要把 commit 抽出來，單獨處理。

應用場景2：有時候開發分支中的代碼記錄被污染了，導致開發分支合到線上分支有問題，這時就需要拉一條干凈的開發分支，再從舊的開發分支中，把 commit 復制到新分支。

復制單個

現在有一條feature分支，commit 記錄如下：

需要把 b 復制到另一個分支，首先把 commitHash 復制下來，然後切到 master 分支。

當前 master 最新的記錄是 a，使用 cherry-pick 把 b 應用到當前分支。

完成後看下最新的 log，b 已經應用到 master，作為最新的 commit 了。可以看到 commitHash 和之前的不一樣，但是提交時間還是保留之前的。微信搜索公眾號：java後端編程，回復：java 領取資料 。

復制多個

以上是單個 commit 的復制，下面再來看看 cherry-pick 多個 commit 要如何操作。

上面的命令將 commit1 和 commit2 兩個提交應用到當前分支。

上面的命令將 commit1 到 commit2 這個區間的 commit 都應用到當前分支（包含commit1、commit2），commit1 是最早的提交。

在 cherry-pick 多個commit時，可能會遇到代碼沖突，這時 cherry-pick 會停下來，讓用戶決定如何繼續操作。下面看看怎麼解決這種場景。

還是 feature 分支，現在需要把 c、d、e 都復制到 master 分支上。先把起點c和終點e的 commitHash 記下來。

切到 master 分支，使用區間的 cherry-pick 。可以看到 c 被成功復制，當進行到 d 時，發現代碼沖突， cherry-pick 中斷了。這時需要解決代碼沖突，重新提交到暫存區。

然後使用 cherry-pick --continue 讓 cherry-pick 繼續進行下去。最後 e 也被復制進來，整個流程就完成了。

以上是完整的流程，但有時候可能需要在代碼沖突後，放棄或者退出流程：

回到操作前的樣子，就像什麼都沒發生過。

不回到操作前的樣子。即保留已經 cherry-pick 成功的 commit，並退出 cherry-pick 流程。

給定一個或多個現有提交，恢復相關提交引入的更改，並記錄一些這些更改的新提交。這就要求你的工作樹是干凈的（沒有來自頭部的修改）。

將現有的提交還原，恢復提交的內容，並生成一條還原記錄。

應用場景：有一天測試突然跟你說，你開發上線的功能有問題，需要馬上撤回，否則會影響到系統使用。這時可能會想到用 reset 回退，可是你看了看分支上最新的提交還有其他同事的代碼，用 reset 會把這部分代碼也撤回了。由於情況緊急，又想不到好方法，還是任性的使用 reset，然後再讓同事把他的代碼合一遍（同事聽到想打人），於是你的技術形象在同事眼裡一落千丈。

revert 普通提交

學會 revert 之後，立馬就可以拯救這種尷尬的情況。

現在 master 記錄如下：

revert 掉自己提交的 commit。

因為 revert 會生成一條新的提交記錄，這時會讓你編輯提交信息，編輯完後 :wq 保存退出就好了。

再來看下最新的 log，生成了一條 revert 記錄，雖然自己之前的提交記錄還是會保留著，但你修改的代碼內容已經被撤回了。

在 git 的 commit 記錄里，還有一種類型是合並提交，想要 revert 合並提交，使用上會有些不一樣。

現在的 master 分支里多了條合並提交。

使用剛剛同樣的 revert 方法，會發現命令行報錯了。為什麼會這樣？在官方文檔中有解釋。

通常無法 revert 合並，因為您不知道合並的哪一側應被視為主線。此選項指定主線的父編號（從1開始），並允許 revert 反轉相對於指定父編號的更改

我的理解是因為合並提交是兩條分支的交集節點，而 git 不知道需要撤銷的哪一條分支，需要添加參數 -m 指定主線分支，保留主線分支的代碼，另一條則被撤銷。

-m 後面要跟一個 parent number 標識出"主線"，一般使用 1 保留主分支代碼。

還是上面的場景，在 master 分支 revert 合並提交後，然後切到 feature 分支修復好 bug，再合並到 master 分支時，會發現之前被 revert 的修改內容沒有重新合並進來。

因為使用 revert 後， feature 分支的 commit 還是會保留在 master 分支的記錄中，當你再次合並進去時，git 判斷有相同的 commitHash，就忽略了相關 commit 修改的內容。

這時就需要 revert 掉之前 revert 的合並提交，有點拗口，接下來看操作吧。

現在 master 的記錄是這樣的。

再次使用 revert，之前被 revert 的修改內容就又回來了。

此命令管理重錄中記錄的信息。

如果說 reset --soft 是後悔葯，那 reflog 就是強力後悔葯。它記錄了所有的 commit 操作記錄，便於錯誤操作後找回記錄。

應用場景：某天你眼花，發現自己在其他人分支提交了代碼還推到遠程分支，這時因為分支只有你的最新提交，就想著使用 reset --hard ，結果緊張不小心記錯了 commitHash，reset 過頭，把同事的 commit 搞沒了。沒辦法， reset --hard 是強制回退的，找不到 commitHash 了，只能讓同事從本地分支再推一次（同事瞬間拳頭就硬了，怎麼又是你）。於是，你的技術形象又一落千丈。

分支記錄如上，想要 reset 到 b。

誤操作 reset 過頭，b 沒了，最新的只剩下 a。

這時用 git reflog 查看 歷史 記錄，把錯誤提交的那次 commitHash 記下。

再次 reset 回去，就會發現 b 回來了。

對我這種喜歡敲命令而不用圖形化工具的愛好者來說，設置短命令可以很好的提高效率。下面介紹兩種設置短命令的方式。

打開全局配置文件

寫入內容

本文主要分享了5個在開發中實用的 Git 命令和設置短命令的方式。

文中列舉的應用場景有部分不太恰當，只是想便於同學們理解，最重要的是要理解命令的作用是什麼，活學活用才能發揮最大功效。

好啦，今天的分享就到這兒啦，我們下次見啦~