課程地址 《版本控制入門 – 搬進 Github》

筆記參考 《搬進 Github》

Git客戶端的使用

Git for windows下載

新建一個倉庫tata，使用sublime新建一個文件hello，如圖

回到GitHub客戶端，如下所示，顯示了文件的變化，如果只需要先提交hello，可單擊good所在的行忽略good

在左下角填寫對本次提交的描述：

點擊History可查看歷史提交

如果要撤回提交，則在changes中選擇undo即可。但是undo操作只適用於還沒有同步的版本，即還沒有同步到Github網站上。可通過如下操作進行撤回

沒有找到版本回滾，好像是取消了，還是通過命令行進行了版本回退操作。原來覺得命令行有些麻煩，有點怕使用，但其實想想應該多用命令行，掌握基本的操作其實也不難。

將本地倉庫同步到Github網站上，點擊

私有為付費項目，取消選中，填寫描述，過一會可在自己的Github網站上看到同步成功的倉庫

簡單分支操作

創建新分支

如下創建一個新分支idea

如下，分支idea創建成功，打鉤表明當前指針指向idea分支

默認情況下這個 idea 分支只是存在於本地，如果想在遠端倉庫上發布這個分支，就點一下 idea 分支右側的 Publish 按鈕。

這樣，到遠端倉庫看一下，發現多了一個 idea 分支，輸入框中不但能搜索已有分支，還能創建新分支。很多操作在本地客戶端和 github.com 上都能進行。

刪除分支

合並分支

切換到要合並到的分支，例為master，選擇Branch中的Merge into current branch

選擇要合並到mater的分支，點擊merge into master即完成合並操作。merge 之後， master 分支指針指向了 merge commit，也就自動擁有了 idea 分支上的最新版本了。idea 分支一般這會兒就可以刪除了。

master 中擁有了 idea 中的所有代碼。底層歷史變成了這樣

新生成了一個 C5 ，這是一個“融合版本”（ Merge Commit ）這個合並挺特殊，裏面一般沒有修改內容，它的作用主要是把兩個分支合並起來。怎麽合並的呢？把 master 的內容 sync 到 github.com 上，然後查看一下這個 merge commit ，會發現它有兩個 parent

代碼沖突 conflicts

實際中經常有這樣的情況，我正在 idea 分支上開發一個比較大的功能。但是這個時候突然發現了一個緊急的問題需要修復，所以我會直接到 master 分支上，做一個 commit 來解決這個緊急的問題。然後會來繼續到 idea 上開發。

其他的情形也有，總之這樣就會出現，兩個不同分支上並行開發，同時都有新的 commit ，這個一般沒有問題，一樣可以直接 merge ，如下圖

但是如果在兩個分支上改動了同一個地方，合並的就會出現代碼沖突。 因為 git 不知道該聽哪個分支的，所以只能報出沖突的位置，讓開發者手動解決。

來具體操作一下。在 idea 分支上，改動 hello文件中的一行，比如改成 AAA，commit 了，然後切換到 master 分支上，把這一行的內容改為 BBB ，也一樣做 commit。這樣再到客戶端，把 idea 分支 merge 到 master 之中，操作不會直接成功，而是會看到下面的代碼沖突界面。

右擊打開存在沖突的文件，看到如下內容

<<<<<<< HEAD
BBB
=======
AAA
>>>>>>> idea

註意上面的 HEAD 是代表當前分支，此刻對應我的情形就是 master 。所以 ===== 就是兩個沖突代碼塊的分界線了。上面的代碼就是 master 分支上的，下面的代碼是 idea 分支的。解決沖突就是把上面的三行“沖突標示符”都刪掉，然後修改代碼。之後，回到客戶端，點擊 2 處的 Commit to Master 。 這樣，這次分支合並就完成了，也會生成一個 merge commit 。

合並分支除了融合（ merge ）還有另外一種形式叫”變基“（ rebase ）這裏暫時用不上，先不管。

團隊合作流程

Github 多年來總結出來一套自己的團隊協作流程，簡單而且強大，叫做 Github Flow ，網站上的各個功能都是圍繞著這個流程來開發的。另，中文版的 Github Flow 在這裏 。

要了解一個流程，沒有什麽比跑一個最簡單的實際例子更好的方式了，官方給出的Hello World就是服務於這個目的，不過這個 Hello World 用的是純粹的網頁來實現整個流程。

給隊友添加寫權限

Settings->collaborator　　

開分支並在上面開發

發 Pull Request

PR 在整個 Github Flow 流程中占有核心位置。其實 PR 的目的就是討論，且整個討論過程是圍繞著實打實的代碼。

先到倉庫頁面，找到發 PR 的大綠按鈕

下面圖中顯示的界面中，看1處，註意一下是拿出哪兩個分支來進行對比。2處，我要填寫一些內容，解釋一下我的修改內容。3處，可以上傳圖片。同樣在這個頁面上，滑動到下方還可以看到這次 PR 的具體對比出來的代碼內容

點擊 Create Pull Request 按鈕，這樣發 PR 就成功了。

補充一句。實際上，客戶端中也可以發 PR，達成的效果跟網頁中發是一樣的，這裏就不演示了。

討論審核代碼

如果代碼需要調整，那我現在是不是要撤銷這 PR 重新發呢？不用。我只需要繼續在分支上改代碼然後再同步上來。

快速 PR

走一遍 Github Flow 其實方式並不唯一。前面討論的，在自己的機器上改代碼，用客戶端作 commit，然後在網頁上發 PR 是一種常見的方式。如果我只是改一個文件中的一個小地方，完全可以使用 github 網頁功能提供的快速 PR這種方法。來演示一下。

網頁界面中，找到我要修改的文件，點擊編輯

在下面的界面中，可以直接填寫一個 Topic 分支名，創建這個分支，並 commit 到這個分支上即可發 PR 了

Github issues

Github 上的每個項目倉庫，都有三套基礎設置可供使用：一個是通過 Github Pages 機制建立項目網站。另外一個就是每個項目都可以開自己的 wiki ，作為項目的知識庫。第三個是事務卡片（ Issues ）。很多比較復雜的項目管理軟件會把“報 Bug ”，“提新需求”，“其他討論”，這些項目相關的內容分成不同的板塊來進行，在 Github 這裏，所有的內容就都作為事務卡片來統一管理了。

更多 Github 技巧

Git客戶端使用教程