1.Git簡介
Git是Linux之父Linus的第二個偉大的作品，它最早是在Linux上開發的，被用來管理Linux核心的源代碼。後來慢慢地有人將其移植到了Unix、Windows、Max OS等操作系統中。
Git是一個分佈式的版本控制系統，與集中式的版本控制系統不同的是，每個人都工作在通過克隆建立的本地版本庫中。也就是說每個人都擁有一個完整的版本庫，查看提交日誌、提交、創建里程碑和分支、合併分支、回退等所有操作都直接在本地完成而不需要網絡連接。
對於Git倉庫來說，每個人都有一個獨立完整的倉庫，所謂的遠程倉庫或是服務器倉庫其實也是一個倉庫，只不過這臺主機24小時運行，它是一個穩定的倉庫，供他人克隆(clone)、推送(push)，也從服務器倉庫中拉取別人的提交(pull)。Git是目前世界上最先進的分佈式版本控制系統。
工作區(working diretory) 用於修改文件
緩存區(stage) 是用來暫時存放工作區中修改的內容
提交歷史（commit history） 提交代碼的歷史記錄
主要的幾個命令
git add # 將工作區的修改提交到暫存區
git commit # 將暫存區的修改提交到當前分支
git reset # 回退到某一個版本
git stash # 保存某次修改
git pull # 從遠程更新代碼
git push # 將本地代碼更新到遠程分支上
git reflog # 查看歷史命令
git status # 查看當前倉庫的狀態
git diff # 查看修改
git log # 查看提交歷史
git revert # 回退某個修改
2.git客戶端下載與安裝
1）官網下載：http://git-scm.com/download/win
由於 Git for Windows.國內直接從官網下載比較困難，需要翻牆。這裏淘寶提供一個國內的下載站，方便下載:
https://npm.taobao.org/mirrors/git-for-windows/
2） git客戶端安裝
參考如下：https://blog.csdn.net/q563573095/article/details/79558067
3.git相關命令詳解
1）git add
刪除文件後需要 git add -A, 光 git add . 不行，區別如下：
git add -A 保存所有的修改
git add . 保存新的添加和修改，但是不包括刪除
git add -u 保存修改和刪除，但是不包括新建文件。
所以默認使用git add -A就行
2）git commit
git commit 主要是將暫存區裏的改動給提交到本地的版本庫。每次使用git commit 命令我們都會在本地版本庫生成一個40位的哈希值，這個哈希值也叫commit-id，commit-id在版本回退的時候是非常有用的，它相當於一個快照,可以在未來的任何時候通過與git reset的組合命令回到這裏。
git commit –m “本次提交描述”
該命令會將git add .存入暫存區修改內容提交至本地倉庫中，若文件未添加至暫存區，則提交時不會提交任何修改。這種是比較常見的用法，-m 參數表示可以直接輸入後面的“message”，如果不加 -m參數，那麼是不能直接輸入message的，而是會調用一個編輯器（一般是vim）來讓你輸入這個message，
message即是我們用來簡要說明這次提交的語句。還有另外一種方法，當我們想要提交的message很長或者我們想描述的更清楚更簡潔明瞭一點，我們可以使用這樣的格式，如下：
git commit -m ‘
message1
message2
message3
’
git commit -a
相當於運行 git add -u把所有當前目錄下的文件加入緩存區域再運行git commit。注意：對於新增的文件，並沒有被commit
git commit –am “本次提交描述”
或者
git commit –a –m“本次提交描述”
等同於上面的-a和-m
git commit --amend //也叫追加提交
修改最近一次提交。有時候如果提交註釋書寫有誤或者漏提文件，可以使用此命令。對於漏提交的文件，需要git add到緩存區之後，git commit --amend才能將修改追加到最近的一次提交上。
即如果我們不小心提交了一版我們不滿意的代碼，並且給它推送到服務器了，在代碼沒被merge之前我們希望再修改一版滿意的，而如果我們不想在服務器上abondon，可以通過上述命令在不增加一個新的commit-id的情況下將新修改的代碼追加到前一次的commit-id中。
3）git reset
git reset根據--soft --mixed --hard，會對working tree和index和HEAD進行重置
$ git reset HEAD^
回退版本，一個^表示一個版本，可以多個，另外也可以使用 git reset HEAD~n這種形式。
也可以回退到指定版本：
$ git reset commit-id
soft 參數：git reset --soft HEAD~1 意爲將版本庫軟回退1個版本，所謂軟回退表示將本地版本庫的頭指針全部重置到指定版本，且將這次提交之後的所有變更都移動到暫存區
默認的mixed參數：git reset HEAD～1 意爲將版本庫回退1個版本，將本地版本庫的頭指針全部重置到指定版本，且會重置暫存區，即這次提交之後的所有變更都移動到工作區
hard參數：git reset --hard HEAD～1 意爲將版本庫回退1個版本，但是不僅僅是將本地版本庫的頭指針全部重置到指定版本，也會重置暫存區，並且會將工作區代碼清空（工作區是clean狀態）
注意，soft參數與默認參數都不會修改工作區代碼，只有hard參數纔會修改工作區代碼。
另外，git reset HEAD filename
回退文件，將文件從暫存區回退到工作區（unstage），此時不能帶hard,soft參數
4）git reflog
如果在回退以後又想再次回到之前的版本，git reflog 可以查看所有分支的所有操作記錄（包括commit和reset的操作），包括已經被刪除的commit記錄，git log則不能察看已經刪除了的commit記錄
615ce06 HEAD@{44}: rebase -i (finish): returning to refs/heads/my_test_branch
615ce06 HEAD@{45}: rebase -i (fixup): zancun_new
702356c HEAD@{46}: rebase -i (fixup): # This is a combination of 2 commits.
c997622 HEAD@{47}: rebase -i (reword): zancun_new
fb74ec2 (origin/master, origin/HEAD) HEAD@{48}: rebase -i (start): checkout FETCH_HEAD
f3ef592 HEAD@{49}: commit: zancun3
6b82c75 HEAD@{50}: commit: zancun2
e900fa0 HEAD@{51}: commit: zancun
比如說，回退到commit: zancun3，只需要：
git reset --hard f3ef592 (或者HEAD@{49}) 即可
這個命令對於找回丟失的代碼非常有用。
5）刪除分支
刪除分支：
$ git branch -d branchName
或者， git branch -D branchName 刪除分支（不管它有沒有merge）
前提是先要切換到其他分支
$ git branch -d branch1
error: The branch ‘branch1’ is not fully merged.
If you are sure you want to delete it, run ‘git branch -D branch1’.
6）git push
git push命令用於將本地分支的更新，推送到遠程主機。
$ git push <遠程主機名> <本地分支名>:<遠程分支名>
$ git push origin master
上面命令表示，將本地的master分支推送到origin主機的master分支。如果master不存在，則會被新建。
如果省略本地分支名，則表示刪除指定的遠程分支，因爲這等同於推送一個空的本地分支到遠程分支。
$ git push origin :master
# 等同於
$ git push origin --delete master
上面命令表示刪除origin主機的master分支。如果當前分支與遠程分支之間存在追蹤關係，則本地分支和遠程分支都可以省略。
$ git push origin
上面命令表示，將當前分支推送到origin主機的對應分支。如果當前分支只有一個追蹤分支，那麼主機名(設置了默認主機)都可以省略。
$ git push
如果當前分支與多個主機存在追蹤關係，則可以使用-u選項指定一個默認主機，這樣後面就可以不加任何參數使用 git push推送。
$ git push -u origin master
上面命令將本地的master分支推送到origin主機，同時指定origin爲默認主機，後面就可以不加任何參數使用 git push了。
將當前分支推送到遠程的同名的簡單方法，如下:
$ git push origin HEAD
將當前分支推送到源存儲庫中的遠程引用匹配主機。 這種形式方便推送當前分支(HEAD相當於當前分支的佔位符)，而不考慮其本地名稱。HEAD概念詳解：https://www.cnblogs.com/runnerjack/p/9342362.html
如下:
$ git push origin HEAD:master
單獨使用git push時，沒有指定push的remote分支名，假如當前本地分支名稱與其對應的remote分支名稱不一樣，則會有如下提示：
fatal: The upstream branch of your current branch does not match
the name of your current branch. To push to the upstream branch
on the remote, use
git push origin HEAD:my_new_test_branch
To push to the branch of the same name on the remote, use
git push origin test
To choose either option permanently, see push.default in 'git help config'.
7）git pull
git pull命令用於從另一個存儲庫或本地分支獲取並集成(整合)。git pull命令的作用是：取回遠程主機某個分支的更新，再與本地的指定分支合併。
$ git pull <遠程主機名> <遠程分支名>:<本地分支名>
比如，要取回origin主機的master分支，與本地的test分支合併，需要寫成下面這樣
$ git pull origin master:test
如果遠程分支(master)要與本地當前分支合併，則冒號後面的部分可以省略。上面命令可以簡寫：
$ git pull origin master
將遠程存儲庫中的更改合併到當前分支中。在默認模式下，git pull是git fetch後跟git merge FETCH_HEAD的縮寫。
更準確地說，git pull使用給定的參數運行git fetch，並調用git merge將檢索到的分支頭合併到當前分支中。 使用–rebase，它運行git rebase而不是git merge。也就是說
git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase
git fetch將遠程主機的最新內容拉到本地，用戶在檢查了以後決定是否合併到工作本機分支中。
而git pull則是將遠程主機的最新內容拉下來後直接合並，即：git pull = git fetch + git merge，這樣可能會產生衝突，需要手動解決。
git pull中fetch命令是將遠程分支的最新內容拉到了本地，但是fetch後是看不到變化的，此時本地多了一個FETCH_HEAD的指針，checkout到該指針後可以查看遠程分支的最新內容。然後checkout到master分支，執行merge,選中FETCH_HEAD指針,合併後如果出現衝突則需要手動解決衝突。
什麼是衝突
合併的時候，有可能會產生衝突。衝突的產生是因爲在合併的時候，不同分支修改了相同的位置。所以在合併的時候git不知道那個到底是你想保留的，所以就提出疑問（衝突提醒）讓你自己手動選擇想要保留的內容，從而解決衝突。
git merge和 git rebase
1)git merge
將 origin 分支合併到 mywork 分支最簡單的辦法就是用下面這些命令
git checkout mywork
git merge origin
或者，也可以把它們壓縮在一行裏:
git merge origin mywork
假設遠程分支上有3次提交A,B,C:
在遠程分支origin的基礎上創建一個名爲"mywork"的本地分支並提交了修改E，同時有其他人在"origin"上做了一些修改並提交了修改D。
用git merge命令把"origin"分支與本地提交合並（merge）成版本M，mywork 分支中新的合併提交（merge-commit）將兩個分支的歷史連在了一起，但這樣會形成圖中的菱形，讓人很困惑。
Merge 好在它是一個安全的操作，比較安全，現有的分支不會被更改，避免了 rebase 潛在的缺點（後面會說）。另一方面，這同樣意味着每次合併上游更改時 feature 分支都會引入一個外來的合併提交。如果 master非常活躍的話，這或多或少會污染你的分支歷史。雖然高級的 git log 選項可以減輕這個問題，但對於開發者來說，還是會增加理解項目歷史的難度。
2)git rebase
作爲 merge 的替代選擇，rebase可以像下面這樣將 mywork 分支併入 origin 分支：
git checkout mywork
git rebase origin
它會把整個 mywork 分支移動到 origin 分支的後面，有效地把所有 master 分支上新的提交併入過來。但是，rebase爲原分支上每一個提交創建一個新的提交，重寫了項目歷史，並且不會帶來合併提交。rebase的好處是避免了菱形的產生，保持提交曲線爲直線，讓大家易於理解。
rebase最大的好處是你的項目歷史會非常整潔。首先，它不像 git merge 那樣引入不必要的合併提交。其次，如上圖所示，rebase 導致最後的項目歷史呈現出完美的線性——你可以從項目終點到起點瀏覽而不需要任何的 fork。這讓你更容易使用 git log、git reset 和 gitk 來查看項目歷史。
不過，這種簡單的提交歷史會帶來兩個後果：安全性和可跟蹤性。如果你違反了 rebase 黃金法則，重寫項目歷史可能會給你的協作工作流帶來災難性的影響。此外，rebase 不會有合併提交中附帶的信息——你看不到 mywork 分支中併入了上游的哪些更改。
在rebase的過程中，有時也會有conflict，這時Git會停止rebase並讓用戶去解決衝突，解決完衝突後，用git add命令去更新這些內容，然後不用執行git commit,直接執行git rebase --continue,這樣git會繼續apply餘下的補丁。
在任何時候，都可以用git rebase --abort參數來終止rebase的行動，並且mywork分支會回到rebase開始前的狀態。
官方的兩張merge和rebase對比圖：
merge示例圖：
rebase示例圖：
3)rebase的高級操作–交互式rebase
交互式的 rebase 允許你更改併入新分支的提交。這比自動的 rebase 更加強大，因爲它提供了對分支上提交歷史完整的控制。一般來說，這被用於將 feature 分支併入 master 分支之前，清理混亂的歷史。
把 -i 傳入 git rebase 選項來開始一個交互式的rebase過程：
git checkout feature
git rebase -i master
它會打開一個文本編輯器，顯示所有將被移動的提交：
pick e900fa0 zancun
pick 6b82c75 zancun2
pick f3ef592 zancun3
# Rebase fb74ec2..f3ef592 onto fb74ec2 (3 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
這個列表定義了 rebase 將被執行後分支會是什麼樣的。更改 pick 命令或者重新排序，這個分支的歷史就能如你所願了。比如說，如果第二個和第三個提交只是修復了第一個提交中的小問題，你可以用 fixup 命令把它們合到第一個提交中，並修改第一個的日誌：
r e900fa0 zancun
f 6b82c75 zancun2
f f3ef592 zancun3
這樣三個提交合併成了一個提交，並可以重新修改提交日誌，非常實用。
忽略不重要的提交會讓你的 feature 分支的歷史更清晰易讀。這是 git merge 做不到的。
4)Rebase的黃金法則
當你理解rebase是什麼的時候，最重要的就是什麼時候不能用rebase。git rebase 的黃金法則便是，絕不要在公共的分支上使用它。
比如說，如果你把 master分支rebase到你的feature 分支上會發生什麼：
這次 rebase 將 master 分支上的所有提交都移到了 feature 分支後面。問題是它只發生在你的代碼倉庫中，其他所有的開發者還在原來的 master 上工作。因爲 rebase 引起了新的提交，Git 會認爲你的 master 分支和其他人的 master 已經分叉了。
同步兩個 master 分支的唯一辦法是把它們 merge 到一起，導致一個額外的合併提交和兩堆包含同樣更改的提交。不用說，這會讓人非常困惑。
所以，在你運行 git rebase 之前，一定要問問你自己「有沒有別人正在這個分支上工作」。如果答案是肯定的，那麼把你的爪子放回去，重新找到一個無害的方式（如 git merge）來提交你的更改。不然的話，你可以隨心所欲地重寫歷史。
4.github使用場景
1)上傳本地項目到github庫中步驟可參考： https://blog.csdn.net/Lucky_LXG/article/details/77849212
https://www.cnblogs.com/mr-wuxiansheng/p/6974170.html
第一次創建倉庫並上傳github命令如下：
echo "# test" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/Sniperliangzhu/test.git
git push -u origin master
push已存在的repository到遠程倉庫（github)命令如下：
git remote add origin https://github.com/Sniperliangzhu/test.git
git push -u origin master
2)本地創建分支並提交到github參考：https://blog.csdn.net/daerzei/article/details/79530418
5.參考文檔
https://blog.csdn.net/weelyy/article/details/82823798#t8