工做中 Git 使用流程 commit 提交規範 提交一條沒有衝突的MR

工做中 Git 飛行姿式

記錄使用git的一些姿式，沒那麼細節，但都是一些工做中經常使用的。

配置用戶名稱和郵箱

# 全局設置
git config --global user.name "username"
git config --global user.email "username@email.com"
# 針對項目單獨配置 須要進到相對應的項目根目錄
git config --local user.name "username"
git config --local user.email "username@email.com"
複製代碼

修改遠程倉庫地址

由於我每次忘記命令，結果都去改文件裏面地址:joy:好氣呀。

# 查看
git remote show origin 
# 直接命令添加
# 若是存在則要先刪除
git remote rm origin
git remote add origin [url]
# 命令修改
git remote origin set-url [url]
# 這都記不住！（跟我同樣）
# 修改config文件吧
複製代碼

開發新需求

記得從最新的master分支中切出來一個新的分支出去開發

# 拉取master分支最新的代碼
git pull --rebase
# 建立新的需求分支
git checkout -b feature/xxxx
# coding...
複製代碼

解決某問題

記得從最新的master分支中切出來一個新的分支出去開發

# 拉取master分支最新的代碼
git pull --rebase
# 建立問題分支（兩種名稱均可以主要是要統一）
git checkout -b hotfix/xxxx
# git checkout -b fix/xxxx
# coding...
複製代碼

commit

每次的commit最好仍是要作commit內容格式化的不要讓別的看你的commit信息的時候都是update，更新，修復，新增，刪除這些之類的太不明確的詞語:triumph:，不說別人看到怎麼樣子，我是接受不了這樣的提交信息的。

版本回退

在咱們的實際開發中老是會有各類各樣的問題，那麼咱們就須要它了 reset 版本回退。

# 對於本地的 commit 尚未提交到遠程分支
# 首先看一下咱們的 commit id 
git log
# 複製你想要回退的commit id
# --soft 保存文件狀態到 添加暫存區後
# --mixed（默認）保存文件狀態到 未添加暫存區
# --hard 不保存文件狀態回退
git reset --hard [commit id]
# HEAD~ 回退到上一次 commit
# 沒有加 --hard 則保存 commit 狀態就是 status
git reset HEAD~
# 回退到前面三個 commit 位置
git reset HEAD~3
複製代碼

cherry-pick

git cherry-pick 能夠理解爲挑揀獲取某個分支的單次提交，而且做爲一個新的 commit 引入到你當前操做分支上面。這個命令也是頗有用滴～

# 基本格式
git cherry-pick [<options>] <commit-id>
# options
# --quit 退出當前的cherry-pick序列
# --continue 繼續當前的cherry-pick序列
# --abort 退出當前的cherry-pick序列 恢復當前分支到沒有 pick 前狀態
複製代碼

push

在咱們的工做裏面都會有不少次的push代碼

每次的推送請保證當前分支是最新的代碼

# 基本格式
git push <遠程主機名> <本地分支名>:<遠程分支名>
# 省略遠程分支名稱
# 推送到跟本地分支名稱相同的遠程分支 若是沒有則會被新建
git push origin master
# 省略本地分支名 等於推送一個空分支
# 表示會刪除這指定的遠程分支！
git push origin :master
# 刪除遠程分支（上面的等同於這條命令）
git push origin --delete master
# 強制推送 -f or --force 會強行是本地分支覆蓋遠程分支
# 儘可能避免強制推送 除非你知道你本身在作什麼
git push --force
# 這個命令在個人理解只有在作代碼 rebase（下面有講到） 的時候纔會用
# 我本身的理解就是不會讓你 rebase 過來的代碼影響原本分支的時間線
git push --force-with-lease
# 沒有option 默認推送當前分支到遠程 規則同上前面幾條
git push
複製代碼

代碼rebase

當咱們經歷過漫長的開發週期的時候，這個需求分支終於開發完畢，能夠上線了，可是咱們歷來都沒有 rebase 過咱們的代碼。實際上是建議在需求分支上面天天結束的時候git rebase master一樣也要保證master是最新的，你會問什麼是？爲何要？ 固然建議是在一個新的分支上面堅持這麼作，不然最後的 rebase 可能會使你感到有點崩潰（當有不少次的 commit ）。

1. 會讓你知道你和master分支具體會有那些衝突，這些衝突會由你本身解決，而不是在你提MR的時候，由合併者去解決存在的代碼衝突。
2. 同時也會加快工做的效率。
3. master上面的版本時間線會是一條筆直漂亮的線，而不是很雜亂，同時也利於版本回退。
4. 總的來講利大於弊（天天 rebase 會浪費時間？）

# 在 master 分支拉取最新代碼
git pull --rebase
# 切換到開發的需求分支上面
# 我試過好像不能直接 rebase 遠程 master 分支
git rebase master
# 開始 rebase 過程當中容易出現的問題
# 代碼衝突 rebase 就會中止下來 當前的分支會停在一個臨時的分支上面讓你解決衝突（不要慌） 沒有什麼大的問題 正常解決衝突 完事記得 git add .
# 繼續 rebase
git rebase --continue 
# 若是還有衝突 還會循環上面步驟
# 還有就是 rebase 過程當中停在了臨時分支上面 你去 idea 上面看的時候 也沒有發現什麼衝突的 這時候就應該跳過這個了
git rebase --skip
# 這時候又進入正常 rebase 過程
# 剩下的就是重複上面的步驟了
# 還有就是如何中止呢 當你發現 rebase 出現的不可預測的問題 好比本身一臉懵逼 或者誤操做 或者...
# 中止它 而且回到沒有 rebase 以前狀態
git rebase --abort
# 當 rebase 完成的時候 當前分支會自動切回來 剩下的就是我上面講到的
git push --force-with-lease
複製代碼

merge

到這裏基本上就能夠開心去提 MR（沒有衝突的） 啦～

• 你的代碼裏有你讀過的書和走過的路
• 經歷過纔會有更好的成長

博客地址 歡迎到訪

GitHub 我不要Star✨（瘋狂暗示）