是否可以执行 git-rebase 而不是执行 git-pull
我开始从 NASM 源文件重写一些 Perl 程序。 我已经对我自己的工作副本做了一些提交,并且我想知道我是否应该执行 git rebase,而不是执行 git pull。
我几乎已经决定我应该进行 git rebase ,但我不知道如何重新设计我的存储库以达到这种效果,或者即使这是可能的。
I started to rewrite some of the Perl programs from the NASM source files. I have already done a few commits to my own working copy, and I was wondering if, instead of doing git pull
, I should have been doing git rebase
.
I have pretty much decided that I should have been doing a git rebase
, but I don't know how to rework my repository to achieve that effect, or even if it is possible.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
这是可能的,Git Magic 教程将解释如何做它。 但是如果其他人看到了您的分支,那就不安全。 即使没有其他人见过你的分支,我也敦促你重新考虑。
为什么要进行变基? 为什么不直接拉/合并?
变基的目的是重写历史,以便您的存储库
反映了您认为您的软件应该发展的方式
它实际上是怎样做的。 这什么时候很重要? 当你是一个
分布式开发团队的初级成员,而你没有
提交权限 - 相反,您所能做的就是将补丁提交到
看门人并希望他们被接受。 为了最大化机会
接受后,您想要重写历史以使您的补丁成为
尽可能干净、清晰。 这个开发模式是不是听起来很熟悉?
Manoj Srivastava 写了一篇对 rebase-vs-merge 进行了相当深思熟虑的分析 。
It is possible, and the Git Magic tutorial will explain how to do it. But if anyone else has seen your branch, it is unsafe. Even if nobody else has seen your branch, let me urge you to reconsider.
Why have rebasing? Why not just pull/merge?
The purpose of rebasing is to rewrite history so that your repository
reflects the way you believe your software should have evolved instead
of the way it actually did. When is this important? When you are a
junior member of a distributed development team, and you don't have
commit privileges—instead, all you can do is submit patches to a
gatekeeper and hope that they are accepted. To maximize the chances
of acceptance, you want to rewrite history to make your patches as
clean and clear as possible. Is the development model sounding familiar?
Manoj Srivastava has written a fairly thoughtful analysis of rebase-vs-merge.
我过去使用以下方法取得了成功:
对于此方法,我添加了以下别名:
当从远程仓库拉取更改时:
YMMV
I've had success with the following method in the past:
For this method, I have added the following alias:
When pulling in changes from the remote repo:
YMMV
git log
git reset HEAD^
下次我建议执行
git fetch
,然后按照步骤 3 进行变基。我建议为当前 git 存储库创建一个小 tarball,以防变基出错。 当您感到更有信心时,您会减少这样做的次数(通常您可以使用 git 修复几乎所有内容,但有时 tarball 更快)。
git log
git reset HEAD^
Next time I recommend to do a
git fetch
and then the rebase as step 3.I would recommend to create a small tarball of your current git repo, just in case the rebase goes wrong. You'll do that less often when you feel more confident (and usually you can fix almost everything with git, but sometimes the tarball is faster).
您应该能够通过更改分支来撤消上次合并,如下所示:
之后您可以尝试变基。
You should be able to undo your last merge by changing the branches like this:
After that you can try rebasing.
作为达斯汀回复的后续,它应该是“git config --globalbranch.master.rebase true”。
As a followup to Dustin's reply, it should be "git config --global branch.master.rebase true".