Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

git 实践之 —— 脏 PR 处理(2)

  使用 cherry-pick 处理脏 PR 的方案逻辑上虽然容易理解,但实际操作起来还是比较麻烦的。如果 commit 的数量不多的话还好说,如果有几十个 commit,一个个 cherry-pick 过来,一个个解冲突那就太累的,而且还容易出错。现在再给大家介绍一种处理脏 PR 的方案。
  rebase 是个强大的命令,如果当前分支上修改的代码与 rebase 目标的代码有重复部分就可以自动被过滤掉。那么利用这个性质,我们可以将一个巨大的 commit 中已经存在与 base 的部分代码从 commit 中删除掉。
  当拿到一个脏分支时可以先看看这个脏分支是基于主分支的哪个 commit 的。假设主仓库的 remote 叫 origin,主分支叫 master。使用 merge-base 可以直接找到这个 commit 的 hash。 git merge-base HEAD origin/master   我们 rebase 到这个 commit,然后把它之后的所有 commit 全部合并起来。rebase -i 会进入交互模式,进入后可以看到操作提示信息。 git rebase $(git merge-base HEAD origin/master) -i   对于这一坨 commit,我们希望对第一个(最旧的)重命名,其它的全部合并到第一个上。那么我们应该把第一个 pick 改成 r,后面的所有 pick 改成 f。如果编辑器是 vim 的话手动改掉第一个 r,然后一个正则替换过去 :%s/^pick/f   最后保存后会先进入 commit 改名,结束后即可得到一个巨大的 commit,这个 commit 包含了当前功能的所有代码以及 merge 的代码。接下来我们 rebase 到主分支上,将 merge 的代码从这个 commit 中抽取出去。这个操作可能会冲突,解决冲突后即可得到一个只剩下当前功能代码的 commit。 git rebase origin/master   比起 cherry-pick 方案,这个方案的优点是全都是批量操作,不用纠结 commit 到底有多少个。需要解决的冲突也比 cherry-pick 的方案少。但缺点是最终只剩下一个 commit。当然也可以在合并的阶段分成多个 commit 合并,最终可以得到多个 commit,只不过这个操作会比较繁琐,因为 rebase 的时候可能有一坨 merge 过来的 commit 在干扰我们合并。
网名:
3.80.32.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^