git基础
1、stash****:存储临时代码。
stash 命令能够将还未 commit 的代码存起来,让你的工作目录变得干净。
命令使用
你只需要:
git stash
就这么简单,代码就被存起来了。
当你修复完线上问题,切回 某个分支,想恢复代码也只需要:
git stash apply
相关命令
保存当前未commit的代码
git stash
保存当前未commit的代码并添加备注
git stash save "备注的内容"
列出stash的所有记录
git stash list
删除stash的所有记录
git stash clear
应用最近一次的stash
git stash apply
应用最近一次的stash,随后删除该记录
git stash pop
删除最近的一次stash
git stash drop
2、reset --soft****:软回溯,回退 commit 的同时保留修改内容。
描述
完全不接触索引文件或工作树(但会像所有模式一样,将头部重置为)。这使您的所有更改的文件更改为“要提交的更改”。
回退你已提交的 commit,并将 commit 的修改内容放回到暂存区。
一般我们在使用 reset 命令时,git reset --hard会被提及的比较多,它能让 commit 记录强制回溯到某一个节点。而git reset --soft的作用正如其名,--soft(柔软的) 除了回溯节点外,还会保留节点的修改内容。
应用场景
回溯节点,为什么要保留修改内容?
应用场景1:有时候手滑不小心把不该提交的内容 commit 了,这时想改回来,只能再 commit 一次,又多一条“黑历史”。
应用场景2:规范些的团队,一般对于 commit 的内容要求职责明确,颗粒度要细,便于后续出现问题排查。本来属于两块不同功能的修改,一起 commit 上去,这种就属于不规范。这次恰好又手滑了,一次性 commit 上去。
命令使用
学会reset --soft之后,你只需要:
恢复最近一次 commit
git reset --soft HEAD^
reset --soft相当于后悔药,给你重新改过的机会。对于上面的场景,就可以再次修改重新提交,保持干净的 commit 记录。
以上说的是还未 push 的commit。对于已经 push 的 commit,也可以使用该命令,不过再次 push 时,由于远程分支和本地分支有差异,需要强制推送git push -f来覆盖被 reset 的 commit。
还有一点需要注意,在reset --soft指定 commit 号时,会将该 commit 到最近一次 commit 的所有修改内容全部恢复,而不是只针对该 commit。
3、cherry-pick****:复制 commit。
描述
给定一个或多个现有提交,应用每个提交引入的更改,为每个提交记录一个新的提交。这需要您的工作树清洁(没有从头提交的修改)。
将已经提交的 commit,复制出新的 commit 应用到分支里
应用场景
commit 都提交了,为什么还要复制新的出来?
应用场景1:有时候版本的一些优化需求开发到一半,可能其中某一个开发完的需求要临时上,或者某些原因导致待开发的需求卡住了已开发完成的需求上线。这时候就需要把 commit 抽出来,单独处理。
应用场景2:有时候开发分支中的代码记录被污染了,导致开发分支合到线上分支有问题,这时就需要拉一条干净的开发分支,再从旧的开发分支中,把 commit 复制到新分支。
命令使用
复制单个
需要把 b 复制到另一个分支,首先把 commitHash 复制下来,然后切到 master 分支。
复制多个
以上是单个 commit 的复制,下面再来看看 cherry-pick 多个 commit 要如何操作。
- 一次转移多个提交:
git cherry-pick commit1 commit2
上面的命令将 commit1 和 commit2 两个提交应用到当前分支。
- 多个连续的commit,也可区间复制:
git cherry-pick commit1^..commit2
上面的命令将 commit1 到 commit2 这个区间的 commit 都应用到当前分支(包含commit1、commit2),commit1 是最早的提交。
(***1)切到 master 分支,使用区间的cherry-pick。发现代码冲突,cherry-pick中断了。这时需要解决代码冲突,重新提交到暂存区。
然后使用cherry-pick --continue让cherry-pick继续进行下去。最后 e 也被复制进来,整个流程就完成了。
以上是完整的流程,但有时候可能需要在代码冲突后,放弃或者退出流程:
- 放弃 cherry-pick:
git cherry-pick --abort
回到操作前的样子,就像什么都没发生过。
- 退出 cherry-pick:
git cherry-pick --quit
不回到操作前的样子。即保留已经cherry-pick成功的 commit,并退出cherry-pick流程。
4、revert****:撤销 commit 的修改内容。
描述
给定一个或多个现有提交,恢复相关提交引入的更改,并记录一些这些更改的新提交。这就要求你的工作树是干净的(没有来自头部的修改)。
将现有的提交还原,恢复提交的内容,并生成一条还原记录。
应用场景
应用场景:有一天测试突然跟你说,你开发上线的功能有问题,需要马上撤回,否则会影响到系统使用。这时可能会想到用 reset 回退,可是你看了看分支上最新的提交还有其他同事的代码,用 reset 会把这部分代码也撤回了。由于情况紧急,又想不到好方法,还是任性的使用 reset,然后再让同事把他的代码合一遍(同事听到想打人),于是你的技术形象在同事眼里一落千丈。
命令使用
revert 普通提交
学会 revert 之后,立马就可以拯救这种尴尬的情况。
现在 master 记录如下:
git revert 21dcd937fe555f58841b17466a99118deb489212
revert 掉自己提交的 commit。
因为 revert 会生成一条新的提交记录,这时会让你编辑提交信息,编辑完后 :wq 保存退出就好了。
再来看下最新的 log,生成了一条 revert 记录,虽然自己之前的提交记录还是会保留着,但你修改的代码内容已经被撤回了。
5、reflog****:记录了 commit 的历史操作。
描述
此命令管理重录中记录的信息。
如果说reset --soft是后悔药,那 reflog 就是强力后悔药。它记录了所有的 commit 操作记录,便于错误操作后找回记录。
应用场景
应用场景:某天你眼花,发现自己在其他人分支提交了代码还推到远程分支,这时因为分支只有你的最新提交,就想着使用reset --hard,结果紧张不小心记错了 commitHash,reset 过头,把同事的 commit 搞没了。没办法,reset --hard是强制回退的,找不到 commitHash 了,只能让同事从本地分支再推一次(同事瞬间拳头就硬了,怎么又是你)。于是,你的技术形象又一落千丈。
命令使用
分支记录如上,想要 reset 到 b。
误操作 reset 过头,b 没了,最新的只剩下 a。
这时用git reflog查看历史记录,把错误提交的那次 commitHash 记下。
再次 reset 回去,就会发现 b 回来了。
详细:说几条可以提高效率的 Git 命令
6、强制推送push
git push -f
作用场景:
当第一次把本地代码提交到你一个新建的远程空仓库,如果有冲突,推送不上去,第一次的时候可以使用强制推送命令,直接覆盖远程仓库所有东西
****7、分支合并 ****
假设有一个master和layout分支,需要把layout分支代码合并到maste分支,
(1)先切换到layout分支 推送当前最新代码到远程仓库
git checkout layout
git add .
git commit -m 'fest: 【项目名称】推送内容'
git pull //拉取代码下来后,如果有冲突,解决冲突
git push
(2) 再切换回到需要合并代码的master分支(就是把layout分支代码合并到maste的分支),并且拉取该分支的最新代码,查看是否有冲突,假设有冲突就解决冲突
git checkout master
git pull //拉取代码下来后,如果有冲突,解决冲突
(3) master分支没有冲突代码后,就可以合并分支了
目前是在master分支,就是在合并代码的时候,需要把代码合并到某个分支,当前就应当位于某个分支内,然后再把另一个分支的代码,合并到当前所处的分支
git merge layout
上面的merge命令就合并代码了,假设代码合并后有冲突,就解决冲突
(4)再把合并代码后的master分支,推送上远程仓库
git add .
git commit -m 'fest: 【项目名称】推送内容'
git pull //拉取代码下来后,如果有冲突,解决冲突
git push
版权归原作者 A-超 所有, 如有侵权,请联系我们删除。