Git Rebase 简单解释
Rebase 可能是最容易被误解的 git 命令。
几乎每个与我合作的初级开发人员都对此感到恐惧git rebase
。
讽刺的是,rebase
这是我几乎每天都会用到的少数 git 命令之一。一般来说,我在 GitHub 上发起的每次拉取请求,我都会至少 rebase 一次。
我重新设置基准以确保我的提交消息有意义并且我的分支不会出现任何严重的、意外的合并冲突。
git rebase
一旦您掌握了命令的工作原理和用途,使用该命令就不必太复杂或令人生畏。
假设你有两个分支。
第一个看起来像这样:
3def6294 One more change that I made
579db95b Another change I made
f261ebba Some change that I made
13363dd3 Rails 5.2 features: enable cache ...
73188cd8 Sidekiq: add test helpers (#5326)
ba424854 Enable cache logging in development if requested (#5330)
51df3255 Change MentionJob to MentionWorker ...
第二个看起来像这样:
242c6eb5 Change from after_create to ...
c64bfdb6 Handle missing commentable ...
cb98b3b5 pages bust cache job sidekiq refactor (#5338) [deploy]
df042d6b Refactors ActiveJob ...
783d43b7 Change create first reaction job to worker (#5327) [deploy]
c1638cfd Create UpdateAnalyticsWorker to replace UpdateAnalyticsJob (#5331)
040b36bc Fix event propagation for click on tag rules in editor (#5280) [deploy]
ba230eca Allow language-xxx class detection on pre tags in ReverseMarkdown (#5299)
13363dd3 Rails 5.2 features: enable cache ...
73188cd8 Sidekiq: add test helpers (#5326)
ba424854 Enable cache logging in development if requested (#5330)
51df3255 Change MentionJob to MentionWorker ...
如果你仔细观察,你会发现这两个分支从基部到13363dd3
分叉处都是相同的。
第一个分支(从现在开始我将把它称为我们的工作分支)有三个在第二个分支中不存在的提交。
第二个分支(在此示例中我将其称为 master)有八个提交,这些提交在我们的工作分支中不存在。
事实上,这种情况非常容易发生。当你创建一个功能分支,并与许多其他开发人员(例如 DEV)一起开发项目时,你很容易就能复制这种情况。
如果您的功能分支存在了几天,那么在您将分支合并回主分支之前,主分支很可能会发生变化。
在这种情况下,如果您可以将功能分支恢复到主分支并将更改提升到 git 历史记录的顶部,那将非常方便。
如果我们将工作分支恢复到 master 并将这三个提交放在顶部,它可能会看起来像这样:
3def6294 One more change that I made
579db95b Another change I made
f261ebba Some change that I made
242c6eb5 Change from after_create to ...
c64bfdb6 Handle missing commentable ...
cb98b3b5 pages bust cache job sidekiq refactor (#5338) [deploy]
df042d6b Refactors ActiveJob ...
783d43b7 Change create first reaction job to worker (#5327) [deploy]
c1638cfd Create UpdateAnalyticsWorker to replace UpdateAnalyticsJob (#5331)
040b36bc Fix event propagation for click on tag rules in editor (#5280) [deploy]
ba230eca Allow language-xxx class detection on pre tags in ReverseMarkdown (#5299)
13363dd3 Rails 5.2 features: enable cache ...
73188cd8 Sidekiq: add test helpers (#5326)
ba424854 Enable cache logging in development if requested (#5330)
51df3255 Change MentionJob to MentionWorker ...
做这样的事情会使针对 master 的拉取请求更加清晰,并帮助我们避免合并冲突。
幸运的是,这就是重新定基分支的有效方法!
我们来谈谈这个命令的名字:Rebase。它是什么意思呢?
如果您将这两个 git 分支想象成树干(树的比喻在 git 中是恒定的),您可以想象我们想用主分支的基础替换工作分支的基础。
换句话说,我们想用主分支“重新定位”工作分支。
让我们来看一下变基过程。
我在 rebase 时几乎总是使用-i
(也就是 interactive 的)标志,因为它可以更轻松地修改提交信息、压缩提交或重新排序提交。该git rebase
命令的这些功能超出了本文的讨论范围,因此我们暂时先不讨论,但我鼓励你尝试一下 interactive 标志。
相反,假设我们已经working-branch
在本地机器上签出了,那么重新定基就很简单了:
git rebase master
您会看到一些控制台输出:
First, rewinding head to replay your work on top of it...
Applying: Some change that I made
Applying: Another change I made
Applying: One more change that I made
你可以看到 git 正在 master 分支上“重放”我们的工作,就像录音一样。这对于理解 rebase 的工作原理来说也是一个不错的比喻。
当我们注销我们的 git 历史记录时,您会看到我们的更改已在主分支顶部重播。
3def6294 One more change that I made
579db95b Another change I made
f261ebba Some change that I made
242c6eb5 Change from after_create to ...
c64bfdb6 Handle missing commentable ...
cb98b3b5 pages bust cache job sidekiq refactor (#5338) [deploy]
df042d6b Refactors ActiveJob ...
783d43b7 Change create first reaction job to worker (#5327) [deploy]
c1638cfd Create UpdateAnalyticsWorker to replace UpdateAnalyticsJob (#5331)
040b36bc Fix event propagation for click on tag rules in editor (#5280) [deploy]
ba230eca Allow language-xxx class detection on pre tags in ReverseMarkdown (#5299)
13363dd3 Rails 5.2 features: enable cache ...
73188cd8 Sidekiq: add test helpers (#5326)
...
换句话说,我们用 master 重新建立了我们的分支。
如果您仍然害怕使用 rebase,请尝试在运行 rebase 命令之前复制您的工作分支,以确保安全!
还有更多...
这些天我写了很多文章,我运营着一个播客,并且我已经开始发送一份关于我听到的所有精彩故事的新闻通讯摘要。
您还可以在Twitter上关注我,在那里我会制作一些有趣的表情包并谈论作为一名开发人员的感受。
文章来源:https://dev.to/jacobherrington/git-rebase-explained-simply-k0a