原副标题：掌控强悍的 Git 变基指示 | Linux 我国
编者按：自学怎样采用 Git 来挖空、变基和优选。
责任编辑页数：4703，写作时数约： 6两分钟
自学怎样采用 Git 来挖空、变基和优选。
当我与自己谈到 Git 时，基本上每一人都对 git rebase 指示 🔗 opensource.com 有两极化的第一印象，那个指示让许多人碰到了难题，而不得已更动产品目录、删掉库房、接着再再次布季夫两个库房。我指出这是因为她们误会了组成部分是怎样组织工作，碰到了两个十分差劲的预设介面，除了许多分拆武装冲突把事搞得一塌糊涂。
是不是找不出 git squash 指示？
假如你曾在邻近地区的库房递交过很数次，并期望能把那些递交都分拆为两个提交，接下去，我们就来如是说能用甚么 Git 指示达至那个目地。Git 称那个基本概念为 “ 挖空递交 (squash commits) ”。我在撰写文件格式时辨认出了那个基本概念：我花了十多个递交才修正好我的 Markdown 文件格式，但库房的贡献者不该看见我的大部份试著，以防搅乱了此项目地发展史，因此我被知会“须要挖空你的递交”。
挖空递交听出来是两个很管用的方式。但多于两个难题：我不晓得该是不是做。做为 Git 的初学者，我做了其他人会做的事：我去翻查 git-squash 的指南，但我立刻碰到了妨碍：
$ mangit–squash
>Nomanual entry forgit–squash
我辨认出没有两个名为 squash 的 Git 指示，而是被要求 运行两个完全独立的指示：git rebase 指示 🔗 opensource.com ，该指示能将我的大部份递交最终分拆为两个递交。
我晓得我碰到两个常见的情形：已经采用工具一段时间的人采用了行话或引用了两个基本概念，那个基本概念对她们来说是十分清楚的，但对初学者来说就不能明白了。从基本概念上讲，那个情况看出来是这样的：
Image of 6 bowls of different colored spices, and an arrow pointing to the second image of all the spices blended into one bowl.
我这样说是为了鼓励你，你绝对不是第两个或最后两个 被 Git 或谈论 Git 的人弄糊涂的人。你可以要求对方说明白他的意见，并帮助你应该采用的正确指示。库房的贡献者实际上的意思是，“采用 git rebase 指示**，将很多递交挖空成两个递交”。
现在就来自学 git rebase 指示吧
git rebase 指示会将两个递交链从其第两个父级中删掉，并将其放置在另两个递交链的末尾，将两个递交链组合成两个长链，而不是两个并行链。我意识到这是两个很复杂的定义。
回想一下 Git 的递交是怎样链接在一起的，你可以看见，除了初始的 main （或 master ）组成部分外，任何组成部分都有两个 父递交 (parent commit) 做为该链的 “ 基础 (base) ”。“ 变基 (rebase) ” 能使另两个链中的最后两个递交成为指定组成部分的新 “ 基础递交 (base commit) ”。
在 Git 中整合来自不同组成部分的修正主要有两种方式： 分拆 (merge) 以及 变基 (rebase) ，你可能更熟悉 git merge 指示。接下去，就来看看 [ git-scm.com 🔗 git-scm.com ] 是怎样解释 git merge 和 git rebase 的差异：
Image of Git merge versus git rebase shown as numbered bubbles.
在分拆示例中，它会把两个组成部分的最新快照（ C3 和 C4 ）以及二者最近的共同祖先（ C2 ）进行三方分拆，分拆的结果是生成两个新的快照（ C5 ）。 experiment 的组成部分指针仍然存在，仍然指向 C4 。
在变基示例中，它提取在 C4 中引入的补丁和修正，接着在 C3 的基础上应用一次，使 C3 成为 C4 的新父级，并产生了两个名为 C4 的新递交。
（LCTT 译注：具体的指示如下：
$ gitcheckout experiment
$ gitrebase main
First,rewinding headto replay your work on topof it…
Applying:added staged command
它的原理是首先找到这两个组成部分 —— 即当前组成部分 experiment 、变基操作的目标基底组成部分 main —— 的最近共同祖先 C2 ，接着对比当前组成部分相对于该祖先的历次递交，提取相应的修正并存为临时文件，接着将当前组成部分指向目标基底 C3 ，最后以此将之前另存为临时文件的修正依序应用。）
值得注意的是，组成部分指针 main 没有移动。要让 Git 将指针移动到链的末尾（由 experiment 指向），你还须要执行分拆。
（LCTT 译注：具体的指示如下：
$ gitcheckout main
$ gitmerge experiment
master 组成部分的快进分拆
此时， C4 指向的快照就和上面采用 merge 指示的例子中 C5 指向的快照一模一样了。）
git rebase 并不能替代 git merge 。 git rebase 是一种用于制作更清晰的发展史记录，以与 git merge 结合采用的工具。
（LCTT 译注：采用 git rebase 指示将递交到某一组成部分上的大部份修正都移至另一组成部分上，就好像“再次播放”一样。）
交互式变基能给你两个更友好的介面！
从指示行执行 git rebase 指示，最可怕的地方在于它 差劲的预设介面。运行指示 git rebase <target-refr> 要么有效，要么会变得一塌糊涂，因为它没有太多的反馈或方式来确保它做你想做的事。幸运的是， git rebase 指示和许多其他 Git 指示一样，具有 交互模式 (interactive mode) ，你可以采用参数 -i 或者 -interactive 来采用交互模式。
Image of the Git lens interactive Rebase tool in VS Code.
在采用交互式模式时， git rebase 会从两个差劲的黑框介面转换为两个 选项菜单，允许你选择对正在变基的递交链所做的事。对于每一递交，你可以 选择：
◈ 选用 (pick) ：按原样包含
◈ 重写 (reword) ：重写递交消息
◈ 撰写 (edit) ：在变基完成之前对递交中的文件进行进一步更动
◈ 挖空 (squash) ：将多个递交压缩成两个递交，保留大部份递交消息
◈ 修理 (fixup) ：将多个递交压缩成两个递交，但只保留最后两个递交消息
◈ 丢弃 (drop) ：丢弃此递交
就我个人而言，我更喜欢 VS Code 的开源 GitLens 扩展 🔗 marketplace.visualstudio.com 采用下拉选择列表布局选项的方式，但 Git 允许你采用任何编辑器选择那些选项。对于 Emacs 或 Vim 等纯文本工具，你须要键入选择，而不是从菜单中选择，但最终结果仍然是相同的。
何时做变基
晓得 何时做变基与晓得 怎样做变基同样重要。事实上，假如你不在乎你的库房历史递交消息有点混乱的话，那么你可以永远都不采用 git rebase 指示。但，假如你想要更干净的发展史递交消息，并且想要更少搅乱你的图形视图的递交，那么当你采用 git rebase 指示时，有两个重要的经验法则须要时刻记住：
“不要变基你存储库以外的的递交，那些递交可能是自己组织工作的基础。”
假如你遵循该准则，不会发生甚么大难题的。
简而言之，假如你让两个 邻近地区组成部分来完成你的组织工作，变基是没有难题的。但一旦该组成部分被 推送 (push) 了，就不要再变基该组成部分了。当然，你想要是不是做完全取决于你自己。
期望你会指出上述内容有助于你理解 git rebase 指示的组织工作原理，并能让你更有信心地采用它。与任何 Git 指示一样，练习是自学和理解是不是做的唯一方式。我鼓励你勇敢地试著 交互式变基 (interactive rebase) git rebase -i <branch name> ！
接下去自学 Git cherry-pick 指示吧
大多数开发人员将修正递交到某一组成部分上，但之后辨认出她们一直 递交到了错误的组成部分上。理想情况下，她们可以拿走那个递交，接着把它移到正确的组成部分，这正是 git cherry-pick 指示的作用。
git cherry-pick 指示利用了变基单个递交的方式。这一用法十分常见，以至于有了它自己的指示。
Image of a woman picking a cherry from one tree and putting on another tree.
要采用 git cherry-pick ，你只需告诉 Git 你要移动到“那个组成部分”的递交 ID（由 HEAD 指向）：
$ gitcherry–pick <target–ref>
假如出现难题，你可以根据 Git 提供的错误消息，来进行恢复：
$ gitcherry–pick –i 2bc01cd
Auto–merging README.md
CONFLICT (content):Mergeconflict inREADME.md
error:could notapply 2bc01cd…added EOF lines
hint:Afterresolving the conflicts,mark them with
hint:“git add/rm “,thenrun
hint:“git cherry-pick –continue”.
hint:Youcan instead skip thiscommit with“git cherry-pick –skip”.
hint:Toabort andgetback to the state before“git cherry-pick”,
hint:run “git cherry-pick –abort”.
$ gitcherry–pick —abort
让 Git 更强悍
git rebase 指示是 Git 实用程序强悍的地方之一。你最好在测试库房中先练习一下是不是采用，一旦你熟悉了它的基本概念和组织工作流程，你就可以给库房两个清晰发展史消息记录了。
via: https://opensource.com/article/22/11/advanced-git-commands
作者： Dwayne McDaniel 选题： lkxed 译者： chai001125 校对： wxy
责任编辑由 LCTT 原创编译， Linux我国 荣誉推出
LCTT 译者 ：chai001125
🌟🌟🌟
翻译： 21.0篇
|
贡献： 62天
2022-10-06
→
2022-12-07
https://linux.cn/lctt/chai001125
欢迎遵照 CC-BY-SA 协议规定转载，
如需转载，请在文章下留言 “ 转载：公众号名称”，
我们将为您添加白名单，授权“ 转载文章时可以修正”。
