文章目錄

Git的優點
（1）適合分佈式開發，強調個體。
（2）公共服務器壓力和數據量都不會太大。
（3）速度快、靈活。
（4）相對容易的解決衝突。
（5）大部分操作在本地完成，不需要聯網。
（6）以快照流的方式工作

一、Git基本使用

Git官網下載：https://git-scm.com/

1. 準備工作

Git目錄說明
工作目錄：任意目錄下，我們開發代碼的目錄
暫存區域：.git目錄下，作用：有個後悔（返回撤銷）的餘地
本地倉庫：.git目錄下，Git存儲項目的倉庫

（1）新建一個本地庫

首先找到一個任意的路徑當做本地庫目錄，點擊右鍵 --> Git Bash Here
然後會彈出一個命令框，進行初始化本地庫，輸入：
```
git init
```
執行完該命令後，在當前目錄會出現隱藏文件夾： .git

.git目錄的出現表示本地庫初始化成功（表示這個.git目錄就是我們的本地庫了）
注意：.git目錄存放的是和本地庫相關的文件，不要修改或者刪除

（2）設置簽名

設置簽名的作用：區分不同開發人員的身份
注意：爲Git設置簽名與遠程庫（代碼託管中心）的賬號密碼沒有任何關係

設置簽名命令，git命令行中執行：

本地庫級別設置簽名方式：
```
git config user.name zs
git config user.email [email protected]
```
信息保存位置：./.git/config 文件

系統用戶級別設置簽名方式：

git config --global user.name zs
git config --global user.email [email protected]

信息保存位置：~/.gitconfig 文件

優先級按照就近原則：項目級別優先於系統用戶級別，二者都有時採用項目級別的簽名。

2. 版本管理

將工作目錄的代碼先提交到暫存區，然後再由暫存區提交到本地倉庫：

（1）基本命令（查看記錄/提交到本地庫）：

git status：查看工作區、暫存區狀態
- 紅色表示文件沒有添加到暫存區
- 綠色表示文件添加到暫存區後沒有添加到本地倉庫
- 沒有任何文件展現，說明工作區，暫存區，本地庫中的文件信息處於同步（相同）狀態。
git add [file name]：將工作區的信息（變化）添加到暫存區
git commit -m "msg" [file name]：將暫存區的內容提交到本地庫，不寫filename默認爲所有文件
git commit -am "msg"：相當於將上面的兩條命令合併爲一條命令
git log：查看本地庫更新歷史記錄
git log --oneline：查看本地庫更新歷史記錄（簡化版）
git reflog：查看本地庫更新歷史記錄（展現HEAD指針）（常用）

（2）版本管理

git reset --hard [局部索引值]：基於索引值的操作，讓版本回退到索引值的位置，局部索引值使用的是git reflog查出來的前n位數
git reset --hard HEAD^ ：表示後退操作一個^表示後退一步，N個^表示後退N步
git diff 文件名：將工作區中的文件和暫存區進行比較
git diff 本地庫中歷史版本(局部索引值) 本地中的文件名：將本地文件與本地庫的歷史版本進行比較

（3）分支管理

git branch -v：查看分支（綠色高亮的、命令行後括號中均爲當前使用的分支）
git 分支名：創建分支
git checkout 分支名：切換分支
git merge 分支名：將分支名中的信息與當前所在的分支進行整合
- 分支的合並不會刪除某一個分支，而是對於信息進行對稱整合，難免會出現衝突，出現衝突後，如下圖所示，會有衝突地方的標誌，需要手動解決衝突（留有用信息（協商解決），刪除（作爲衝突標識的）特殊符號）
  
  修改完衝突後再次提交解決衝突：

分支管理的好處：
（1）同時並行推進多個功能開發，提高開發效率
（2）各個分支在開發過程中，如果某一個分支開發失敗，不會對其他分支有任何影響。失敗的分支刪除重新開始即可。

二、GitHub基本使用

GitHub官網：https://github.com/

1. 創建遠程庫

點擊右上角的+號，選擇New Repository創建新的倉庫
爲倉庫起名字，並設置權限爲公有的或私有的

2. 訪問遠程庫

點擊左側菜單中的遠程庫，也會進入到該遠程庫信息頁面
點擊HTTPS，會得到訪問遠程庫的地址

3. 邀請其他GitHub用戶加入開發團隊

打開遠程庫信息頁面，點擊settings，點擊Collaborators，輸入被邀請人賬號，點擊Add collaborator
將獲取到的邀請鏈接，發送給被邀請人，被邀請人登錄賬號後在地址欄訪問邀請鏈接，點擊Accept invitaion 接受邀請

三、Idea對於Git&GitHub的支持

1. 基本配置

（1）配置GitHub

打開File --> settings --> Version Control --> GitHub
填寫GitHub網址，賬號，密碼，然後點擊Test測試

（2）配置Git

打開File --> settings --> Version Control --> Git
第一欄文本框會自動識別到本地Git安裝路徑下cmd/git.exe，點擊Test測試

2. 項目的版本管理

（1）創建本地庫

VCS --> Import into Version Control --> Create Git Repository，選中當前項目作爲本地庫。

操作完成後，會在當前項目的本地看到.git文件夾

（2）提交/上傳/克隆/拉取

項目右鍵/VCS --> Git --> Add：添加到暫存區
項目右鍵/VCS --> Git --> Commit Directory：提交到本地庫（填寫消息，我的習慣是：[姓名][修改的文件類型][文件名]）
項目右鍵/VCS --> Git --> Repository --> Push：提交遠程庫，第一次提交，需要先寫入提交的GitHub庫的名字，以及上傳地址
- 如果設置錯了的話，需要修改項目本地的 .git 文件夾中的config文件，把[remote "origin"]和下面的配置項都刪掉，再回idea中重新push即可

克隆到新的工程（clone）：

先新建一個空的工程
在空的工程中，點擊：VCS --> Checkout from Version Control --> Git，彈出的窗口填寫克隆的地址（URL），克隆的位置選擇當前工程，然後在當前工程中新建一個文件夾，當做是克隆下來的項目的載體
彈出窗口，是否導入工程，選擇是，如果是maven工程則選擇maven，普通工程選擇第一個，然後一頓next即可

拉取修改之後的文件（pull）：

右鍵 --> Git --> Repository --> Pull，或者：
VCS --> Git --> Pull
切記：一定要先拉取再做修改等操作！！！

clone與pull的區別：

clone——無中生有。原來本地是沒有這個項目的，因此將完整的整個項目從倉庫clone到本地
pull——錦上添花。將遠程倉庫中別人做的修改部分pull到本地，讓你本地的項目1.0成爲項目2.0

（3）添加忽略文件

在與 .git 同級目錄下，新建一個文件 .gitignore ，在該文件中添加不需要提交的文件，例如：

文件來不需要加*

.idea
.target
*.iml
*.class

（4）處理衝突

往GitHub上push時發生衝突：在本地處理衝突，衝突處理完後，要重新commit和push

3. 分支

遠程庫上的分支與本地庫的分支是分開的，當使用一個新的分支（遠程庫上沒有該分支）從本地push時，會在遠程庫上創建一個該分支

（1）一些命令

查看本地分支：git branch -v
查看本地及遠程分支：git branch -a

（2）新建/選擇/查看分支

項目右鍵 --> Git --> Repository --> Branches
VCS --> Git --> Branches

（3）GitHub上創建pr(pull requests)並進行整合

當在創建pr產生衝突的時候，需要在GitHub上解決衝突，然後再合併：

解決完衝突後，點擊右上角的Mark as resolved，然後點擊左上角出現的Conmit merge，接下來上圖的Merge pull request 就會變綠，點擊進行整合

四、注意事項

1. 保持原子性的提交

每次提交的間歇儘可能地短，以幾個小時的開發工作爲宜。例如在更改 UI 界面的時候，可以每完成一個 UI 界面的修改或者設計，就提交一次。在開發功能模塊的時候，可以每完成一個小細節功能的測試，就提交一次，在修改 bug 的時候，每修改掉一個 bug 並且確認修改了這個 bug，也就提交一次。我們提倡多提交，也就能多爲代碼添加上保險。

2. 對提交的信息採用明晰的標註

不論是在本機中使用本地庫，還是未來推送到遠程庫，如果提交不明確的標註不僅僅會讓自己懷疑當初提交的目的，也會讓項目組中其他的成員感到很無奈，項目經理無法很清晰的掌握工作進度，無法清晰的把握此次提交的概要信息。在有必要的情況下也不能明確的的回到指定的歷史記錄。所以，在做提交工作時，要填寫明晰的標註，能夠概要的描述所提交文件的信息，讓項目組其他成員在看到標註後不用詳細看代碼就能瞭解你所做的更新。

3. 推送之前先拉取

GitHub拉取的原則是要隨時拉取，隨時推送。當完成了一個小功能，能夠通過編譯並且自己測試之後，謹慎地推送。
如果在修改的期間別人也更改了相同的文件，那麼推送就可能會產生衝突，這種情況就需要同之前的開發人員聯繫，兩個人一起協商解決衝突，解決衝突之後，需要兩人一起測試保證解決衝突之後，程序不會影響其他功能。

4. 不要推送不能通過編譯的代碼

代碼在推送之前，首先要確認自己能夠在本地編譯。如果在代碼中使用了第三方類庫，要考慮到項目組成員中有些成員可能沒有安裝相應的第三方類庫。項目經理在準備項目工作區域的時候，需要考慮到這樣的情況，確保開發小組成員在簽出代碼之後能夠在統一的環境中進行編譯。

5. 不要推送自己不明白的代碼

代碼在推送進入到GitHub之後，你的代碼將被項目成員所分享。如果提交了你不明白的代碼，你看不懂，別人也看不懂，如果在以後出現了問題將會成爲項目質量的隱患。因此在引入任何第三方代碼之前，確保你對這個代碼有一個很清晰的瞭解。

6. 提前協調好項目組成員的工作計劃

 項目經理應該合理分配工作計劃。每個成員在準備開始進行某項功能的修改之前，如果有可能，先跟工作小組的成員談談自己的修改計劃，讓大家都能瞭解你的思想，瞭解你即將對軟件作出的修改，這樣能儘可能的減少在開發過程中可能出現的衝突，提高開發效率。同時你也能夠在和成員的交流中發現自己之前設計的不足，完善你的設計。

Git&GitHub基本使用