工作中 Git 飛行姿勢
記錄使用git的一些姿勢贮预，沒那么細(xì)節(jié)贝室，但都是一些工作中常用的契讲。
配置用戶名稱和郵箱
# 全局設(shè)置
git config --global user.name "username"
git config --global user.email "username@email.com"
# 針對項(xiàng)目單獨(dú)配置 需要進(jìn)到相對應(yīng)的項(xiàng)目根目錄
git config --local user.name "username"
git config --local user.email "username@email.com"
修改遠(yuǎn)程倉庫地址
因?yàn)槲颐看瓮浢睿Y(jié)果都去改文件里面地址:joy:好氣呀滑频。
# 查看
git remote show origin
# 直接命令添加
# 如果存在則要先刪除
git remote rm origin
git remote add origin [url]
# 命令修改
git remote origin set-url [url]
# 這都記不准衿！（跟我一樣）
# 修改config文件吧
開發(fā)新需求
記得從最新的master分支中切出來一個(gè)新的分支出去開發(fā)
# 拉取master分支最新的代碼
git pull --rebase
# 創(chuàng)建新的需求分支
git checkout -b feature/xxxx
# coding...
解決某問題
記得從最新的master分支中切出來一個(gè)新的分支出去開發(fā)
# 拉取master分支最新的代碼
git pull --rebase
# 創(chuàng)建問題分支（兩種名稱都可以主要是要統(tǒng)一）
git checkout -b hotfix/xxxx
# git checkout -b fix/xxxx
# coding...
commit
每次的commit最好還是要做commit內(nèi)容格式化的不要讓別的看你的commit信息的時(shí)候都是update峡迷，更新银伟，修復(fù)，新增绘搞，刪除這些之類的太不明確的詞語:triumph:彤避，不說別人看到怎么樣子，我是接受不了這樣的提交信息的看杭。
版本回退
在我們的實(shí)際開發(fā)中總是會(huì)有各種各樣的問題忠藤，那么我們就需要它了 reset 版本回退挟伙。
# 對于本地的 commit 還沒有提交到遠(yuǎn)程分支
# 首先看一下我們的 commit id
git log
# 復(fù)制你想要回退的commit id
# --soft 保存文件狀態(tài)到 添加暫存區(qū)后
# --mixed（默認(rèn)）保存文件狀態(tài)到 未添加暫存區(qū)
# --hard 不保存文件狀態(tài)回退
git reset --hard [commit id]
# HEAD~ 回退到上一次 commit
# 沒有加 --hard 則保存 commit 狀態(tài)就是 status
git reset HEAD~
# 回退到前面三個(gè) commit 位置
git reset HEAD^3
cherry-pick
git cherry-pick 可以理解為挑揀獲取某個(gè)分支的單次提交楼雹，并且作為一個(gè)新的 commit 引入到你當(dāng)前操作分支上面。這個(gè)命令也是很有用滴～
# 基本格式
git cherry-pick [<options>] <commit-id>
# options
# --quit 退出當(dāng)前的cherry-pick序列
# --continue 繼續(xù)當(dāng)前的cherry-pick序列
# --abort 退出當(dāng)前的cherry-pick序列 恢復(fù)當(dāng)前分支到?jīng)]有 pick 前狀態(tài)
push
在我們的工作里面都會(huì)有很多次的push代碼
每次的推送請保證當(dāng)前分支是最新的代碼
# 基本格式
git push <遠(yuǎn)程主機(jī)名> <本地分支名>:<遠(yuǎn)程分支名>
# 省略遠(yuǎn)程分支名稱
# 推送到跟本地分支名稱相同的遠(yuǎn)程分支 如果沒有則會(huì)被新建
git push origin master
# 省略本地分支名 等于推送一個(gè)空分支
# 表示會(huì)刪除這指定的遠(yuǎn)程分支尖阔！
git push origin :master
# 刪除遠(yuǎn)程分支（上面的等同于這條命令）
git push origin --delete master
# 強(qiáng)制推送 -f or --force 會(huì)強(qiáng)行是本地分支覆蓋遠(yuǎn)程分支
# 盡量避免強(qiáng)制推送 除非你知道你自己在做什么
git push --force
# 這個(gè)命令在我的理解只有在做代碼 rebase（下面有講到） 的時(shí)候才會(huì)用
# 我自己的理解就是不會(huì)讓你 rebase 過來的代碼影響本來分支的時(shí)間線
git push --force-with-lease
# 沒有option 默認(rèn)推送當(dāng)前分支到遠(yuǎn)程 規(guī)則同上前面幾條
git push
代碼rebase
當(dāng)我們經(jīng)歷過漫長的開發(fā)周期的時(shí)候贮缅，這個(gè)需求分支終于開發(fā)完畢，可以上線了介却，但是我們從來都沒有 rebase 過我們的代碼谴供。其實(shí)是建議在需求分支上面每天結(jié)束的時(shí)候git rebase master同樣也要保證master是最新的，你會(huì)問什么是齿坷？為什么要桂肌？
當(dāng)然建議是在一個(gè)新的分支上面堅(jiān)持這么做，否則最后的 rebase 可能會(huì)使你感到有點(diǎn)崩潰（當(dāng)有很多次的 commit ）永淌。
- 會(huì)讓你知道你和master分支具體會(huì)有那些沖突崎场，這些沖突會(huì)由你自己解決，而不是在你提MR的時(shí)候遂蛀，由合并者去解決存在的代碼沖突谭跨。
- 同時(shí)也會(huì)加快工作的效率。
- master上面的版本時(shí)間線會(huì)是一條筆直漂亮的線李滴，而不是很雜亂螃宙，同時(shí)也利于版本回退。
- 總的來說利大于弊（每天 rebase 會(huì)浪費(fèi)時(shí)間所坯？）
# 在 master 分支拉取最新代碼
git pull --rebase
# 切換到開發(fā)的需求分支上面
# 我試過好像不能直接 rebase 遠(yuǎn)程 master 分支
git rebase master
# 開始 rebase 過程中容易出現(xiàn)的問題
# 代碼沖突 rebase 就會(huì)停止下來 當(dāng)前的分支會(huì)停在一個(gè)臨時(shí)的分支上面讓你解決沖突（不要慌） 沒有什么大的問題 正常解決沖突 完事記得 git add .
# 繼續(xù) rebase
git rebase --continue
# 如果還有沖突 還會(huì)循環(huán)上面步驟
# 還有就是 rebase 過程中停在了臨時(shí)分支上面 你去 idea 上面看的時(shí)候 也沒有發(fā)現(xiàn)什么沖突的 這時(shí)候就應(yīng)該跳過這個(gè)了
git rebase --skip
# 這時(shí)候又進(jìn)入正常 rebase 過程
# 剩下的就是重復(fù)上面的步驟了
# 還有就是如何停止呢 當(dāng)你發(fā)現(xiàn) rebase 出現(xiàn)的不可預(yù)測的問題 比如自己一臉懵逼 或者誤操作 或者...
# 停止它 并且回到?jīng)]有 rebase 之前狀態(tài)
git rebase --abort
# 當(dāng) rebase 完成的時(shí)候 當(dāng)前分支會(huì)自動(dòng)切回來 剩下的就是我上面講到的
git push --force-with-lease
merge
到這里基本上就可以開心去提 MR（沒有沖突的） 啦～
- 你的代碼里有你讀過的書和走過的路
- 經(jīng)歷過才會(huì)有更好的成長
博客地址 歡迎到訪
GitHub 我不要Star?（瘋狂暗示）
