用了5年的source tree，来了字节之后发现大家都喜欢用指令行。什么git rebase;git rebase -i;git cherry-pick;git stash;git commit --amend;这些只在博客里看到的指令全都变成日常了，呜呜呜，真的是栓q。我不论！我不论！我不论！他人都会的我也要会。经过我废寝忘食的学习总算整理出了这份《Git进阶指令精选》，再不好好学面试都不用去了，回家睡觉去吧。

【讲真!】Git进阶精选看这篇就够了

branch办理

  • git checkout -b feat/sass-v1 origin/feat/sass-v1 // 克隆远端分支feat/sass-v1到本地
  • git checkout -b feat/saas-0817 // 从当时分支新建一个分支feat/saas-0817
  • git merge [branchName] 将branchName兼并到当时分支
  • git merge [branchName] –squash 将branchName兼并到当时分支，并将branchName上的一切提交兼并成一次提交
  • git commit --amend 修正上次的提交信息，push后不会增加新的commit记载，可是会修正本次的commithash(也可以理解为删掉了最新的一次commit，重新又提交了一次)

【讲真!】Git进阶精选看这篇就够了

git commit --amend
// 修正commit msg

【讲真!】Git进阶精选看这篇就够了

  • git branch -D [branchName] 删去本地分支
  • git push origin -D [branchName] 删去远端分支

rebase branch

  • git pull –rebase origin [branchName] = git fetch + git rebase
// 假定当时分支dev, commit 为 a b c d e
// 假定master分支, commit 为 a b f g h
git pull --rebase origin master
// 当时分支dev commit 变为 a b c d e f g h
  • git rebase master
// 假定当时分支dev, commit 为 a b c d e
// 假定master分支, commit 为 a b f g h
git rebase origin/master
// 当时分支dev commit 变为 a b f g h c d e

stash储藏代码

  • 场景：当你的功用还没开发完不能commit可是现在需求rebase下master,缓存区的代码该咋办？当你写了几行代码，可是现在需求切到其他分支去改bug，缓存区的代码该咋办？ 用git stash就好啦
  • git stash 储藏代码
  • git stash pop 恢复到作业区和缓存区，会移除stashid
  • git stash list 检查当时储藏区

【讲真!】Git进阶精选看这篇就够了
留意：stash@{0} stash@{1} stash@{2} 是stashname

  • git stash apply stashname 恢复指定储藏代码到作业区和缓存区，会保留stashid
  • git stash save 'msg' 带备注储藏
  • git stash show -p 显现最新的储藏文件详细改动
  • git stash show -p stashname 显现指定的储藏文件详细改动

commit

  • git commit -m “msg” –no-verify 强制提交不检查
  • git push -f 强制提交代码并以本地版别代码为主掩盖远程 git push -f是不安全的，git push --force-with-lease更安全，留意--force-with-lease失利后再履行一次也会强制提交掩盖

reset回退

  • git log 检查提交日志
  • git reset 将一切暂存区回退到作业区
  • git checkout . 丢掉作业区一切的更改
  • git reset –hard [commit hash] 将从commithash(不包括此hash)之后的丢掉
  • git reset –hard 将暂存区、作业区一切内容丢掉
  • git reset --soft [commit hash] 将从commithash(不包括此hash)之后的提交回退到暂存区
  • git reset --soft HEAD~4 回退最近4次提交到暂存区

cherry-pick 仿制提交

  • 场景：当你在merge或许rebase的时候发现冲突太多了，想哭的时候，可以用原分支check目标分支处理，然后再cherry-pick当时分支的每个提交，这样冲突就会少很多。或许另一分支上有些代码还没有merge到master，可是你当时分支又非要用的时候，就可以cherry-pick过来一份。
  • git cherry-pick [commit hash] 将其他分支上已提交的commit在当时分支再提交一次，发生新的commithash

revert

  • git revert [commit hash] 非merge的commit
  • git revert -m [1|2] [commit hash] merge类型的commit
    • 通过git show [commit hash]检查

【讲真!】Git进阶精选看这篇就够了

- 第三行第一个hash为编号1，第二个hash为编号2，以哪个父hash为主线则保留哪个，删去另一个

【讲真!】Git进阶精选看这篇就够了
【讲真!】Git进阶精选看这篇就够了

- git revert -m 1 bd86846 则回滚bd86846的提交，且以ba25a9d master分支为主线保留，回滚掉1c7036f 地点分支提交

rebase -i

  • 场景：运用merge导致git提交线杂乱无章，提交日志过多非常难看。自从运用了rebase提交线变得无比丝滑，运用rebase -i兼并每个需求的一切提交成1个，使日志变得明晰

【讲真!】Git进阶精选看这篇就够了

  • git rebase -i HEAD~10 调整最近10次提交的日志、或兼并多次提交为1次，让log更好看更明晰

p运用, pick = use commit

s兼并掉, squash = use commit, but meld into previous commit

一切的提交按时间倒序排列

被s的会兼并到上一次commit,也便是当时排列的上一个里面

【讲真!】Git进阶精选看这篇就够了

scope

feat: 新功用、新特性

fix: 修正 bug

perf: 更改代码，以提高功用（在不影响代码内部行为的前提下，对程序功用进行优化）

refactor: 代码重构（重构，在不影响代码内部行为、功用下的代码修正）

docs: 文档修正

style: 代码格局修正, 留意不是 css 修正（例如分号修正）

test: 测试用例新增、修正

build: 影响项目构建或依靠项修正

revert: 恢复上一次提交

ci: 持续集成相关文件修正

chore: 其他修正（不在上述类型中的修正）

release: 发布新版别

workflow: 作业流相关文件修正

以上仅为个人学习总结，欢迎评论讨论

【讲真!】Git进阶精选看这篇就够了

觉得不错的记得点个赞哦~

笑死，下面这几篇你们都不看，那你们看啥？

【讲真!】Git进阶精选看这篇就够了

你不得不知的大厂问题复盘方法论

规划模式这样学也太简单了吧！

你不知道的前端软技能