几条很强盛的Git下令

程序员 · 2024-9-7 00:40:17

本文紧张分享了5个在开辟中实用的 Git 下令和设置短下令的方式。
1.stash：存储暂期间码。
2.reset --soft：软回溯，回退 commit 的同时生存修改内容。
3.cherry-pick：复制 commit。
4.revert：打消 commit 的修改内容。
5.reflog：记录了 commit 的汗青使用。
6.rebase：改变当前分支的基点
1.stash

官方表明：当您想记录工作目次和索引的当前状态，但又想返回一个干净的工作目次时，请使用git stash。该下令将生存当地修改，并规复工作目次以匹配头部提交。

stash 下令可以大概将还未 commit 的代码存起来，让你的工作目次变得干净。
应用场景

我猜你心里肯定在想：为什么要变干净？
应用场景：某一天你正在 feature 分支开辟新需求，忽然产物司理跑过来说线上有bug，必须立刻修复。而此时你的功能开辟到一半，于是你急遽想切到 master 分支，然后你就会看到以下报错：

由于当前有文件更改了，必要提交commit保持工作区干净才能切分支。由于环境告急，你只有急遽 commit 上去，commit 信息也任意写了个“暂存代码”，于是该分支提交记录就留了一条黑汗青...(真人真事，看过这种提交)
下令使用

假如你学会 stash，就不消那么狼狈了。你只必要：
git stash就这么简单，代码就被存起来了。
当你修复完线上题目，切回 feature 分支，想规复代码也只必要：
git stash apply干系下令

# 生存当前未commit的代码git stash# 生存当前未commit的代码并添加备注git stash save "备注的内容"# 列出stash的全部记录git stash list# 删除stash的全部记录git stash clear# 应用迩来一次的stashgit stash apply# 应用迩来一次的stash，随后删除该记录git stash pop# 删除迩来的一次stashgit stash drop当有多条 stash，可以指定使用stash，起首使用stash list 列出全部记录：
git stash liststash@{0}: WIP on ...stash@{1}: WIP on ...stash@{2}: On ...应用第二条记录：
git stash apply stash@{1}pop，drop 同理。
2.reset --soft

回退你已提交的 commit，并将 commit 的修改内容放回到暂存区。
一样平常我们在使用 reset 下令时，git reset --hard 会被提及的比力多，它能让 commit 记录强制回溯到某一个节点。而 git reset --soft 的作用正如其名，--soft (柔软的) 除了回溯节点外，还会生存节点的修改内容。
应用场景

回溯节点，为什么要生存修改内容？
应用场景1：偶尔候手滑不鉴戒把不应提交的内容 commit 了，这时想改返来，只能再 commit 一次，又多一条“黑汗青”。
应用场景2：规范些的团队，一样平常对于 commit 的内容要求职责明确，颗粒度要细，便于后续出现题目排查。原来属于两块不同功能的修改，一起 commit 上去，这种就属于不规范。这次恰好又手滑了，一次性 commit 上去。
下令使用

学会 reset --soft 之后，你只必要：
# 规复迩来一次 commitgit reset --soft HEAD^reset --soft 相当于悔恨药，给你重新改过的时机。对于上面的场景，就可以再次修改重新提交，保持干净的 commit 记录。
以上说的是还未 push 的commit。对于已经 push 的 commit，也可以使用该下令，不外再次 push 时，由于长途分支和当地分支有差别，必要强制推送 git push -f 来覆盖被 reset 的 commit。
另有一点必要留意，在 reset --soft 指定 commit 号时，会将该 commit 到迩来一次 commit 的全部修改内容全部规复，而不是只针对该 commit。
举个栗子：
commit 记录有 c、b、a。

reset 到 a
git reset --soft 1a900ac29eba73ce817bf959f82ffcb0bfa38f75此时的 HEAD 到了 a，而 b、c 的修改内容都回到了暂存区。

3.cherry-pick

给定一个或多个现有提交，应用每个提交引入的更改，为每个提交记录一个新的提交。这必要您的工作树干净（没有重新提交的修改）。

将已经提交的 commit，复制出新的 commit 应用到分支里
应用场景

commit 都提交了，为什么还要复制新的出来？
应用场景1：偶尔候版本的一些优化需求开辟到一半，大概此中某一个开辟完的需求要暂时上，大概某些原因导致待开辟的需求卡住了已开辟完成的需求上线。这时间就必要把 commit 抽出来，单独处理处罚。
应用场景2：偶尔候开辟分支中的代码记录被污染了，导致开辟分支合到线上分支有题目，这时就必要拉一条干净的开辟分支，再从旧的开辟分支中，把 commit 复制到新分支。
下令使用

复制单个
现在有一条feature分支，commit 记录如下：

必要把 b 复制到另一个分支，起首把 commitHash 复制下来，然后切到 master 分支。

当前 master 最新的记录是 a，使用 cherry-pick 把 b 应用到当前分支。

完成后看下最新的 log，b 已经应用到 master，作为最新的 commit 了。可以看到 commitHash 和之前的不一样，但是提交时间照旧生存之前的。
复制多个
以上是单个 commit 的复制，下面再来看看 cherry-pick 多个 commit 要怎样使用。
一次转移多个提交：
git cherry-pick commit1 commit2上面的下令将 commit1 和 commit2 两个提交应用到当前分支。
多个一连的commit，也可区间复制：
git cherry-pick commit1^..commit2上面的下令将 commit1 到 commit2 这个区间的 commit 都应用到当前分支（包罗commit1、commit2），commit1 是最早的提交。
cherry-pick 代码辩论

在 cherry-pick 多个commit时，大概会碰到代码辩论，这时 cherry-pick 会停下来，让用户决定怎样继承使用。下面看看怎么办理这种场景。

照旧 feature 分支，现在必要把 c、d、e 都复制到 master 分支上。先把出发点c和尽头e的 commitHash 记下来。

切到 master 分支，使用区间的 cherry-pick。可以看到 c 被成功复制，当举行到 d 时，发当代码辩论，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

将现有的提交还原，规复提交的内容，并天生一条还原记录。
应用场景

应用场景：有一天测试忽然跟你说，你开辟上线的功能有题目，必要立刻撤回，否则会影响到体系使用。这时大概会想到用 reset 回退，但是你看了看分支上最新的提交另有其他同事的代码，用 reset 会把这部门代码也撤回了。由于环境告急，又想不到好方法，照旧任性的使用 reset，然后再让同事把他的代码合一遍（同事听到想打人），于是你的技能形象在同事眼里江河日下。
下令使用

revert 平凡提交
学会 revert 之后，立马就可以救济这种尴尬的环境。
现在 master 记录如下：

revert 掉自己提交的 commit
git revert 21dcd937fe555f58841b17466a99118deb489212
由于 revert 会天生一条新的提交记录，这时会让你编辑提交信息，编辑完后 :wq 生存退出就好了。

再来看下最新的 log，天生了一条 revert 记录，固然自己之前的提交记录照旧会生存着，但你修改的代码内容已经被撤回了。
revert 归并提交
在 git 的 commit 记录里，另有一种范例是归并提交，想要 revert 归并提交，使用上会有些不一样。

现在的 master 分支里多了条归并提交。
使用刚刚同样的 revert 方法，会发现下令行报错了。为什么会如许？在官方文档中有表明。

通常无法 revert 归并，由于您不知道归并的哪一侧应被视为主线。此选项指定主线的父编号（从1开始），并答应 revert 反转相对于指定父编号的更改

我的明确是由于归并提交是两条分支的交集节点，而 git 不知道必要打消的哪一条分支，必要添加参数 -m 指定主线分支，生存主线分支的代码，另一条则被打消。
-m 背面要跟一个 parent number 标识出"主线"，一样平常使用 1 生存主分支代码。
git revert -m 1 <commitHash>revert 归并提交后，再次归并分支会失效
照旧上面的场景，在 master 分支 revert 归并提交后，然后切到 feature 分支修复好 bug，再归并到 master 分支时，会发现之前被 revert 的修改内容没有重新归并进来。
由于使用 revert 后， feature 分支的 commit 照旧会生存在 master 分支的记录中，当你再次归并进去时，git 判断有雷同的 commitHash，就忽略了干系 commit 修改的内容。
这时就必要 revert 掉之前 revert 的归并提交，有点拗口，接下来看使用吧。

现在 master 的记录是如许的。

再次使用 revert，之前被 revert 的修改内容就又返来了。5.reflog

假如说 reset --soft 是悔恨药，那 reflog 就是强力悔恨药。它记录了全部的 commit 使用记录，便于错误使用后找回记录。

应用场景

应用场景：某天你眼花，发现自己在其他人分支提交了代码还推到长途分支，这时由于分支只有你的最新提交，就想着使用 reset --hard，效果告急不鉴戒记错了 commitHash，reset 过头，把同事的 commit 搞没了。
没办法，reset --hard 是强制回退的，找不到 commitHash 了，只能让同事从当地分支再推一次（同事刹时拳头就硬了，怎么又是你）。于是，你的技能形象又江河日下。
下令使用

分支记录如上，想要 reset 到 b。

误使用 reset 过头，b 没了，最新的只剩下 a。

这时用 git reflog 查察汗青记录，把错误提交的那次 commitHash 记下。

再次 reset 回去，就会发现 b 返来了。6.rebase

当执行rebase使用时，git会从两个分支的共同先人开始提取待变基分支上的修改，然后将待变基分支指向基分支的最新提交，末了将刚才提取的修改应用到基分支的最新提交的背面

一、提交节点图解

起首通过简单的提交节点图解感受一下rebase在干什么
构造两个分支master和feature，此中feature是在提交点B处从master上拉出的分支
master上有一个新提交M，feature上有两个新提交C和D

此时我们切换到feature分支上，执行rebase下令，相当于是想要把master分支归并到feature分支（这一步的场景就可以类比为我们在自己的分支feature上开辟了一段时间了，预备从主干master上拉一下最新改动。模拟了git pull --rebase的情况）
# 这两条下令等价于git rebase master featuregit checkout featuregit rebase master下图为变基后的提交节点图，表明一下其工作原理：

feature：待变基分支、当前分支
master：基分支、目的分支
当在feature分支上执行git rebase master时，git会从master和featuer的共同先人B开始提取feature分支上的修改，也就是C和D两个提交，先提取到。然后将feature分支指向master分支的最新提交上，也就是M。末了把提取的C和D接到M背面，留意这里的接法，官方没说清晰，现实是会依次拿M和C、D内容分别比力，处理处罚辩论后天生新的C’和D’。肯定留意，这里新C’、D’和之前的C、D已经不一样了，是我们处理处罚辩论后的新内容，feature指针自然末了也是指向D’
rebase，变基，可以直接明确为改变基底。feature分支是基于master分支的B拉出来的分支，feature的基底是B。而master在B之后有新的提交，就相当于此时要用master上新的提交来作为feature分支的新基底。现实使用为把B之后feature的提交先暂存下来，然后删掉原来这些提交，再找到master的最新提交位置，把存下来的提交再接上去（接上去是逐个和新基底处理处罚辩论的过程），云云feature分支的基底就相当于变成了M而不是原来的B了。（留意，假如master上在B以后没有新提交，那么就照旧用原来的B作为基，rebase使用相当于无效，此时和git merge就根本没区别了，差别只在于git merge会多一条记录Merge使用的提交记录）
上面的例子可抽象为如下现实工作场景：张三从B拉了代码举行开辟，目条件交了两次，开辟到D了；李四也从B拉出来开辟了而且开辟完毕，他提交到了M，然后合到主干上了。此时张三想拉下最新代码，于是他在feature分支上执行了git rebase master，即把master分支给rebase过来，由于李四更早开辟完并合了主干，云云就相当于张三是基于李四的最新提交M举行的开辟了。
假如在rebase的时间提示有辩论，则处理处罚辩论之后执行
git rebase --continue

几条很强盛的Git下令

所属分类: 问答交流

新帖推荐: 30日

推荐作品