在拉取请求后进行Git rebase

8
我在更新一个拉取请求时遇到了问题。
我的操作步骤如下:先fork了一个仓库,将其克隆到本地,创建了一个跟踪upstream/master的分支(pr-branch),提交了一些更改,推送到origin,并打开了一个拉取请求。
现在我需要更新我的拉取请求,但是其他开发人员已经在upstream/master上进行了更改。
所以我执行了以下操作:
1. `git checkout -b master-updated upstream/master` 2. `git pull` 3. `git checkout pr-branch` 4. `git rebase master-updated`
但是Git/SourceTree告诉我,origin/pr-branch和pr-branch已经分叉了: 前者比后者多了126个提交,少了1个提交。(之前我做过一些rebase操作,但从未见过或注意到这种消息…)
接下来我该怎么做呢?
是先进行更改、提交,然后推送到origin? 还是执行pull(但我猜会创建一个合并提交),然后提交并推送到origin?
谢谢!
2个回答

7
更改后,提交然后推送到远程存储库?是的,但这将是一个强制推送:
git push --force

目标是用本地更新的 master 重新变基到你的 pr 分支上,以替换其远程历史记录。

之前我做过一些变基,但从没见过这种消息(或者说没有关注过这种消息...)

经过变基后,出现这种消息似乎是正常的:本地和远程历史记录不再相同。

4

Git的真正优点之一是它没有固定的观点,它允许软件团队选择他们喜欢的工作流程而不强制采用任何特定的工作方式。

谨慎使用rebase

Git rebase 主要用于保持项目历史记录的清晰和线性。然而,这只能通过重写提交历史来实现。

在git中,这些操作被认为是不安全的,特别是对于已发布的历史记录,reset 也有类似的声誉,因此,请使用 revertcheckoutmerge 作为替代。

我对您的问题的理解

我模拟了您的情况,并获得了以下日志历史记录的快照:

git rebase 之前 enter image description here

git rebase之后,显然会改变你旧的提交SHA、时间戳等信息,它正在重写你原始的历史记录,但是你会得到一个线性的日志图。

所以,正如@VonC所提到的,在git rebasegit rebase -i之后,通常需要使用git push -f强制推送你的更改。由于Git已经足够安全,可以提醒开发人员需要强制更新更改,因此开发人员必须自己负责自己的“危险”操作。

推荐阅读

Git以其陡峭的学习曲线而闻名,就像vi或其他一些工具一样。在广泛使用它们之前,了解基础知识总是有益的。我也是Git的新用户,我发现很难了解数百个Git命令/别名/技巧,但我真的发现这篇教程帮助我更好地掌握了Git的基本要点。

https://www.atlassian.com/git/tutorials/what-is-version-control

希望能有所帮助!

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接