git 拉取请求后变基
git rebase after pull request
我无法更新拉取请求。
我做了什么：分叉一个存储库，将其克隆到本地，创建一个跟踪分支 (pr-branch) upstream/master，提交一些更改，推送到源，打开一个拉取请求。
现在我需要更新我的拉取请求，但其他开发人员已在 upstream/master 上进行了更改。
所以我做到了:
git checkout -b master-updated upstream/mastergit pullgit checkout pr-branchgit rebase master-updated
我打算做一些改变，但是 git/source 树告诉我 origin/pr-branch 和 pr-branch 已经分歧：126 领先，1 落后
（我之前做了一些rebase，但从来没有看到（或关注过:-)）这种消息...）
接下来我应该做什么？
进行更改，提交然后推送到源？
拉（但我想创建一个合并提交），提交然后推送到原点？
谢谢！
Make changes, commit then push to origin ?
是的，但推送将是强制推送：
git push --force
目标是用本地分支替换 pr 分支的远程历史（基于更新的上游 master）
126 ahead and 1 behind (I did some rebase before but never saw (or paid attention :-)) this kind of message...)
在变基之后这似乎是意料之中的：本地和远程历史不再相同。
git 的真正优点之一是它不拘一格，它让软件团队可以选择他们喜欢的工作流程，而无需强加任何特定的工作方式。
谨慎使用变基
Git rebase 主要用于维护干净的线性项目历史。然而，这只能通过重写提交历史来实现。
那些行为在git中被认为是不安全，特别是对于公开的历史，reset也有类似的名声，相反，使用revert、checkout 或 merge 作为替代。
我对你的问题的理解
我模拟了您的情况并获得了日志历史记录的以下快照，
之前 git rebase
git rebase之后
显然，git rebase 更改了您的旧提交 SHA、时间戳等，它正在重写您的原始历史记录，但您获得了一个线性日志图。
因此，正如@VonC 所提到的，在 git rebase 或 git rebase -i 之后，您通常必须使用 git push -f 来 force 推送您的变化。由于 git 已经足够安全，可以提醒开发人员更改需要强制更新，因此开发人员必须自己负责他们的 "dangerous" 操作。
推荐读物
Git 以其陡峭的学习曲线而闻名，就像 vi 或其他一些工具一样。在广泛使用它们之前了解基础知识总是好的。我也是 git 的新用户，我发现很难了解数百个 git commands/aliases/tricks，但我真的发现这个教程帮助我更好地理解 git ] 必需品。
https://www.atlassian.com/git/tutorials/what-is-version-control
希望对您有所帮助！
我无法更新拉取请求。
我做了什么：分叉一个存储库，将其克隆到本地，创建一个跟踪分支 (pr-branch) upstream/master，提交一些更改，推送到源，打开一个拉取请求。
现在我需要更新我的拉取请求，但其他开发人员已在 upstream/master 上进行了更改。
所以我做到了:
git checkout -b master-updated upstream/mastergit pullgit checkout pr-branchgit rebase master-updated
我打算做一些改变，但是 git/source 树告诉我 origin/pr-branch 和 pr-branch 已经分歧：126 领先，1 落后
（我之前做了一些rebase，但从来没有看到（或关注过:-)）这种消息...）
接下来我应该做什么？
进行更改，提交然后推送到源？ 拉（但我想创建一个合并提交），提交然后推送到原点？
谢谢！
Make changes, commit then push to origin ?
是的，但推送将是强制推送：
git push --force
目标是用本地分支替换 pr 分支的远程历史（基于更新的上游 master）
126 ahead and 1 behind (I did some rebase before but never saw (or paid attention :-)) this kind of message...)
在变基之后这似乎是意料之中的：本地和远程历史不再相同。
git 的真正优点之一是它不拘一格，它让软件团队可以选择他们喜欢的工作流程，而无需强加任何特定的工作方式。
谨慎使用变基
Git rebase 主要用于维护干净的线性项目历史。然而，这只能通过重写提交历史来实现。
那些行为在git中被认为是不安全，特别是对于公开的历史，reset也有类似的名声，相反，使用revert、checkout 或 merge 作为替代。
我对你的问题的理解
我模拟了您的情况并获得了日志历史记录的以下快照，
之前 git rebase
git rebase之后
显然，git rebase 更改了您的旧提交 SHA、时间戳等，它正在重写您的原始历史记录，但您获得了一个线性日志图。
因此，正如@VonC 所提到的，在 git rebase 或 git rebase -i 之后，您通常必须使用 git push -f 来 force 推送您的变化。由于 git 已经足够安全，可以提醒开发人员更改需要强制更新，因此开发人员必须自己负责他们的 "dangerous" 操作。
推荐读物
Git 以其陡峭的学习曲线而闻名，就像 vi 或其他一些工具一样。在广泛使用它们之前了解基础知识总是好的。我也是 git 的新用户，我发现很难了解数百个 git commands/aliases/tricks，但我真的发现这个教程帮助我更好地理解 git ] 必需品。
https://www.atlassian.com/git/tutorials/what-is-version-control
希望对您有所帮助！