參考：https://mp.weixin.qq.com/s/Km5KuXPETvG0wCGHrvj9Vg
一，git本地版本庫的基本用法
（1）首先初始化一個本地版本庫
命令：git init （版本庫名稱），版本庫名稱可選用不用，如果不加版本庫名稱會初始化為當前文件夾為一個版本庫，加上了名字后會在當前路徑下產生一個文件夾。
初始時git的文件夾如圖所示
執行 git init 命令，不帶版本庫名稱
我們可以看到多了一個.git文件夾，把當前文件目錄當成了一個版本庫
執行 git init 命令，帶版本庫名稱
多了一個test文件夾，且test文件夾之下也生成了一個.git文件夾
（2）查看當前工作區(workspace的狀態)
命令：git status
先進入 test文件夾，然后執行 git status，此時由於是剛剛初始化的本地倉庫，所以目前的狀態是還沒有執行過commit操作過。
（3）把文件添加到暫存區(index)
命令：git add [files]
該命令添加的是當前文件夾下的文件
（4）把文暫存區的文件提交到倉庫
命令：git commit -m "關於這次提交的描述"
（5）查看當前HEAD之前的提交記錄，便於回到過去
命令：git log
（6）回退
命令：git reset -- hard HEAD^^/HEAD~100/commit-id/commit-id的頭幾個字符
報這個錯誤的原因是由於該倉庫目前只有一commit，已經是head版本。
再一次commit后使用git log命令
再使用回退命令后回退成功了
（7）查看當前HEAD之后的提交記錄，便於回到未來
命令：git reflog
（8）回到未來
命令：git reset --hard commit-id/commit-id的頭幾個字符
二，git遠程版本庫的基本用法
先在遠程github上新建一個倉庫
（1）連接到遠程倉庫
命令：ssh -T git@github.com
（2）克隆一個存儲庫到一個新的目錄下
命令 ：git clone [遠程倉庫的地址]
可以看到生成了一個software文件夾
打開該文件夾可以看到改項目已經被克隆了下來
（3）下載一個遠程存儲庫數據對象等信息到本地存儲庫
命令：git fetch
先在遠程修改README.md文件
執行git fetch命令
本地打開發現並沒有更新原來的文件 ，這個時候需要執行下一步的命令
（4）合並兩個或多個開發歷史記錄
命令：git merge
合並上一步的fetch的遠程分支到本地的當前分支
再次打開README.md文件，發現已經更新了
（5）將本地倉庫的相關數據對象更新到遠程倉庫
命令: git push
在本地新建一個文件
需要先使用git add 命令添加到暫存區
然后使用git commit命令提交到本地倉庫
最后再使用git push命令推送到遠程倉庫
再打開github，發現已經有了新的文件
（6）從遠程倉庫或分支抓取並合並到當前倉庫的當前分支
命令：git pull
相當於git fetch 和git merge命令一起執行，默認更新到當前分支
先在遠程倉庫進行修改
然后執行命令
發現本地的文件已經更新了
三，團隊項目中的分叉合並
如果團隊項目像二中的方法一樣多人同時向遠程origin/master分支頻繁提交代碼，一來可能會有諸多沖突合並的情況發生；二來整個git log提交記錄中多個開發者或多個代碼模塊的commit是交錯排列在同一條時間線上，不利於回顧查看和回退代碼，讓跟蹤代碼的成長軌跡變得異常困難。
需要考慮新的方式來能夠獨立維護不同的開發者或者不同的功能模塊的代碼，讓一段連續的工作在commit日志的時間線上呈現為一段獨立的分支線段，只在關鍵節點處進行分支合並。
每一個開發者都采用的工作流程大致如下：
1，克隆或同步最新的代碼到本地庫
2，為自己的工作創建一個分支，改分支應該只負責單一功能模塊或代碼模塊的版本控制
3，在該分支上完成某單一功能模塊或代碼的開發工作
4，最后，將改分支合並到主分支上
（1）把遠程的倉庫克隆下來
（2）為自己的工作創建一個分支，該分支只負責單一模塊或代碼模塊的版本控制
先創建一個分支：命令：git branch [branchName]，當沒有[branchName]的時候會列出在本地分支
然后再切換到自己創建的分支上
命令：git checkout [branchName]
（3）在改分支下進行修改和增加文件的操作
（4）推送到遠程倉庫
先切換為main分支，將遠程 origin/main同步最新到本地倉庫，再合並mybranch到main分支。
最后推送到遠程orign/main 。
在遠程倉庫上可以看到已經進行了修改。
四，Git Rebase
一般我們在軟件開發的流程中，有一個朴素的版本管理哲學：開發者的提交要盡量干凈、簡單。開發者要把自己的代碼修改按照功能拆分成一個個相對獨立的提交，一個提交對應一個功能點，而且要在對應的 commit log message 里面描述清楚。因此在合並和 push 之前檢查修改一下 commit 記錄時常需要。
在上面三中增加一步Git Rebase，即在mybranch分支上完成自己的工作之后，為了讓 log 記錄將來更容易回顧參考，用 git rebase 重新整理一下提交記錄。
注意不要通過rebase對任何已經提交到遠程倉庫中的commit進行修改。
命令：git rebase -i [startpoint] [endpoint]
其中 -i的意思是 --interactive，即彈出交互時的界面讓用戶編輯完成合並操作，[startpoint] [endpoint] 則指定了一個編輯區間，如果不指定 [endpoint]，則該區間的終點默認是當前分支的HEAD。
可以使用HEAD^^、HEAD~100、commit ID或者commit ID的頭幾個字符來指定一個commit節點。
下面完成這么一個例子：
rebase之前的mybranch 分支，有A，B兩個commit：
在mybranch分支合並進來之前，main分支進行了推進：
這個時候在mybranch分支合並到main分支之前進行rebase操作
rebase之前的mybranch分支日志
可以看到，已經沒有 A，B的commit記錄了，但是A，B所執行的修改還保留了下來
使用這個文件在每次提交前進行了 記錄，A操作創建了這個文件，B操作，寫了第一句，after B操作后寫了第二句。此時改文件的內容沒有改變。
然后進行分支合並，把mybranch分支合並到主分支。
合並前的主分支
合並后的主分支
最后推送到遠程倉庫
五，總結
git的版本控制在項目開發中起到的作用非常大，特別是對於多人合作的項目，能夠高效便捷的完成合作開發，同時由於可以進行版本回退的性質，所以對於操作錯誤的容錯性很大，對於團隊項目開發而言，應該盡量使用git，能減少很多的溝通成本，同時對於項目的管理會更加高效。