是否可以执行 git-rebase 而不是执行 git-pull

发布于 2024-07-18 14:24:22 字数 606 浏览 6 评论 0原文

我开始从 NASM 源文件重写一些 Perl 程序。 我已经对我自己的工作副本做了一些提交,并且我想知道我是否应该执行 git rebase,而不是执行 git pull。

我几乎已经决定我应该进行 git rebase ,但我不知道如何重新设计我的存储库以达到这种效果,或者即使这是可能的。

Screenshot-gitk: nasm.crop

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.

Screenshot-gitk: nasm.crop

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

怎言笑 2024-07-25 14:24:22

这是可能的,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.

爱情眠于流年 2024-07-25 14:24:22

我过去使用以下方法取得了成功:

对于此方法,我添加了以下别名:

up = pull --rebase origin
  1. 将您的 master 分支分支为“dev”或其他内容
  2. 在 dev 中工作
  3. 当您完成添加和提交更改后,
  4. git up master
  5. 切换到 master
  6. git merge dev
  7. git push

当从远程仓库拉取更改时:

  1. switch to master
  2. git up
  3. 切换到 dev
  4. git up master

YMMV

I've had success with the following method in the past:

For this method, I have added the following alias:

up = pull --rebase origin
  1. Branch your master branch to something like 'dev' or whatever
  2. Work in dev
  3. when you've finished adding and committing changes
  4. git up master
  5. switch to master
  6. git merge dev
  7. git push

When pulling in changes from the remote repo:

  1. switch to master
  2. git up
  3. switch to dev
  4. git up master

YMMV

忘羡 2024-07-25 14:24:22
  1. 确保当前提交是合并提交: git log
  2. 首先,我们将 master 重新设置为上一个提交(合并之前的提交): git reset HEAD^
    • HEAD^ 表示:“HEAD 引用的提交之前的提交”
  3. 现在你可以进行正常的 rebase: git rebase origin/master

下次我建议执行 git fetch,然后按照步骤 3 进行变基。

我建议为当前 git 存储库创建一个小 tarball,以防变基出错。 当您感到更有信心时,您会减少这样做的次数(通常您可以使用 git 修复几乎所有内容,但有时 tarball 更快)。

  1. Ensure that the current commit is the merge commit: git log
  2. First we re-set the master to the previous commit (the one right before the merge): git reset HEAD^
    • HEAD^ means: 'the commit before the commit referenced by HEAD'
  3. Now you can do a normal rebase: git rebase origin/master

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).

鲜肉鲜肉永远不皱 2024-07-25 14:24:22

您应该能够通过更改分支来撤消上次合并,如下所示:

git branch your-changes <reflog of "Reworked test files...">
git branch -f master remotes/origin/master

之后您可以尝试变基。

You should be able to undo your last merge by changing the branches like this:

git branch your-changes <reflog of "Reworked test files...">
git branch -f master remotes/origin/master

After that you can try rebasing.

你列表最软的妹 2024-07-25 14:24:22

作为达斯汀回复的后续,它应该是“git config --globalbranch.master.rebase true”。

As a followup to Dustin's reply, it should be "git config --global branch.master.rebase true".

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文