一、git基本配置介紹

1. config的三個作用域

• local：區域為本倉庫

• global: 當前用戶的所有倉庫

• system: 本系統的所有用戶

2. 添加最小配置

$ git config --global user.name 'yfy' $ git config --global user.email 'yfy@163.com'

3. 查看配置

$ git config --local --list ?##只能在倉庫里面起作用, 普通路徑git不管理 $ git config --global --list $ git config --system --list

4. 清除設置

$ git config --unset --local user.name $ git config --unset --global user.name $ git config --unset --system user.name

二、git命令

1.git log

? git log --all 查看所有分支的歷史 ? git log --all --graph 查看圖形化的 log 地址 ? git log --oneline 查看單行的簡潔歷史。 ? git log --oneline -n4 查看最近的四條簡潔歷史。 ? git log --oneline --all -n4 --graph 查看所有分支最近 4 條單行的圖形化歷史。 ? git help --web log 跳轉到git log 的幫助文檔網頁

我們可以設置一個別名，自定義git l查看的樣式

alias.l=log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --all

?

2.刪除分支

git branch -d 分支名 ?#在刪除前Git會判斷在該分支上開發的功能是否被merge到其它分支。如果沒有，不能刪除。如果merge到其它分支，但之后又在其上做了開發，使用-d還是不能刪除 git branch -D 分支名 ?#會強制刪除

3.撤銷commit

執行commit后，還沒執行push時，想要撤銷這次的commit，該怎么辦？

git reset --soft HEAD^

如果想要連著add也撤銷的話，--soft改為--hard（刪除工作空間的改動代碼）。

git reset --hard HEAD^ --soft 不刪除工作空間的改動代碼 ，撤銷commit，不撤銷git add file --hard 刪除工作空間的改動代碼，撤銷commit且撤銷add

3.修改commit的message

git commit --amend ?#對最新一次提交做 commit 修改 git rebase -i father_commit_id ?#修改歷史的commit，輸入它的父親節點 git rebase -i --root ?#若沒有父親節點，則用該命令

4.合并commit

我們使用git log命令查看最近3次的提交，我們想要將最近兩次請求合并成一次commit。

?

輸入如下命令:

這里面的commitId是你要合并的兩個commit后所形成的一個commitId需要跟著的commitId。在這邊也就是add log 1的commitId.

git rebase -i commitId

?

進入vi模式后，在鍵盤上敲i鍵進入insert模式。這時候先看看這里面的東西是什么含義，

• pick 的意思是要會執行這個 commit

• squash 的意思是這個 commit 會被合并到前一個commit

我們需要將add log3合并到add log2中，修改成如下：

squash也可以按照上面的注釋所給出的，直接使用簡寫 s

?

wq保存后進入一個新頁面

?

我們可以重新編輯該commit

?

提交完畢后，git log查看我們提交的日志，發現確實合并了

?

5.比較暫存區和HEAD的差異

vi index.html 修改index.html的內容 git add index.html 將修改的文件添加到暫存區 git status 顯示在哪個暫存區 有沒有文件改變將要提交 git diff --cached 查看文件改變情況 看變更的文件有沒有問題 git commit -m 'Add index.html' 做提交操作

6.比較工作區和暫存區的差異

假定：HEAD、緩存區、工作區中的readme.md文件內容均不相同。 git diff HEAD -- readme.md # 工作區 <===> HEAD git diff -- readme.md # 工作區 <===> 暫存區 git diff --cached -- readme.md # 暫存區 <===> HEAD

7.暫存區/工作區恢復到和HEAD一樣

git reset HEAD ? git reset 有三個參數 --soft 這個只是把 HEAD 指向的 commit 恢復到你指定的 commit，暫存區 工作區不變 --hard 這個是 把 HEAD， 暫存區， 工作區 都修改為 你指定的 commit 的時候的文件狀態 --mixed 這個是不加時候的默認參數，把 HEAD，暫存區 修改為 你指定的 commit 的時候的文件狀態，工作區保持不變

8.工作區恢復到暫存區

我們有個文件修改了，然后add到暫存區。然后在工作區繼續開發后，發現改的不是那么理想，想回到暫存區，則執行以下命令。

git restore/checkout 文件名 # 上面2個是git不同版本的命令，效果都一樣。我們可以用git status查看需要使用什么命令

?

9.查看不同提交的文件差異

git diff <commit_id1> <commit_id2> --<file_name> ?#比較某文件兩次不同提交的差異 git diff <branch_1> <branch_2> -- <file_name> ?#比較某文件兩個不同分支的差異

10.刪除文件

git rm filename ?#刪除文件，注意，只是把工作區和暫存區對應的文件刪除了，遠程倉庫的需要push

11.git stash

當開發中臨時加塞了緊急任務怎么處理？

有時候我們會將開發中的代碼先commit，然后新拉一個分支去改臨時需求，改完后合并到主分支中。其它開發更新主分支的代碼，然后繼續開發。

那么，如果我們只是開發了一半，并不想commit呢，我們可以先將代碼存放到暫存區中，當緊急任務開發完畢后，stash pop將代碼恢復，繼續開發。

此時若緊急任務修改的代碼和目前代碼沖突了，兩次更改都在，手動解決沖突即可。

git stash save "save message" #把當前工作區的內容放入暫存區，只有git stash 也要可以的，但查找時不方便識別。 git stash list #查看stash了哪些存儲 git stash pop stash@{$num} #把暫存區的內容恢復到工作區，且刪除，默認為第一個stash,即stash@{0} git stash apply stash@{$num} #把暫存區的內容恢復到工作區，且保留，默認為第一個stash,即stash@{0} git stash drop stash@{$num} #丟棄stash@{$num}存儲，從列表中刪除這個存儲 git stash clear #刪除所有緩存的stash

12.gitignore

我們做的每個Git項目中都需要一個“.gitignore”文件，這個文件的作用就是告訴Git哪些文件不需要添加到版本管理中。

/mtk/ 過濾整個文件夾 *.zip 過濾所有.zip文件 /mtk/do.c 過濾某個具體文件

以上規則意思是：被過濾掉的文件就不會出現在你的GitHub庫中了，當然本地庫中還有，只是push的時候不會上傳。 除了以上規則，它還可以指定要將哪些文件添加到版本管理中。

!src/ ? 不過濾該文件夾 !*.zip ? 不過濾所有.zip文件 !/mtk/do.c 不過濾該文件

配置語法：

• 以斜杠/開頭表示目錄；

• 以星號*通配多個字符；

• 以問號?通配單個字符

• 以方括號[]包含單個字符的匹配列表；

• 以嘆號!表示不忽略(跟蹤)匹配到的文件或目錄；

如果提交commit后，想再忽略一些已經提交的文件，我們可以把想忽略的文件添加到 .gitignore，在使用如下命令：

git rm -- cached name_of_file #刪除掉git倉庫里面無需跟蹤的文件。

三、git開發規范

1.分支命名

master 分支

• master 為主分支，也是用于部署生產環境的分支，確保master分支穩定性

• master 分支一般由develop以及hotfix分支合并，任何時間都不能直接修改代碼

develop 分支

• develop 為開發分支，始終保持最新完成以及bug修復后的代碼

• 一般開發的新功能時，feature分支都是基于develop分支下創建的

feature 分支

• 開發新功能時，以develop為基礎創建feature分支

• 分支命名: feature/ 開頭的為特性分支， 命名規則: feature/user_module、 feature/cart_module

release分支

• release 為預上線分支，發布提測階段，會release分支代碼為基準提測

當有一組feature開發完成，首先會合并到develop分支，進入提測時，會創建release分支。 如果測試過程中若存在bug需要修復，則直接由開發者在release分支修復并提交。 當測試完成之后，合并release分支到master和develop分支，此時master為最新代碼，用作上線。

hotfix 分支

• 分支命名: hotfix/ 開頭的為修復分支，它的命名規則與 feature 分支類似

• 線上出現緊急問題時，需要及時修復，以master分支為基線，創建hotfix分支，修復完成后，需要合并到master分支和develop分支

2.commit規范

當前業界應用的比較廣泛的是 Angular Git Commit Guidelines

格式為：

<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>

• type: 本次 commit 的類型，諸如 bugfix docs style 等

• scope: 本次 commit 波及的范圍

• subject: 簡明扼要的闡述下本次 commit 的主旨

• body: 在主體內容中我們需要把本次 commit 詳細的描述一下，比如此次變更的動機，如需換行，則使用 |

• footer: 描述下與之關聯的 issue 或 break change，詳見案例

Type的類別說明：

• feat: 添加新特性

• fix: 修復bug

• docs: 僅僅修改了文檔

• style: 僅僅修改了空格、格式縮進、都好等等，不改變代碼邏輯

• refactor: 代碼重構，沒有加新功能或者修復bug

• perf: 增加代碼進行性能測試

• test: 增加測試用例

• chore: 改變構建流程、或者增加依賴庫、工具等

總結

以上是生活随笔為你收集整理的git的一些常用命令讲解和开发规范总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。