比方说
在对我们的 fork 进行几次提交之后，我们现在想要将我们的 fork 更新为源项目中的最新 HEAD。因为多人在这个分支上工作，标准的方法是拉下源项目，然后进行合并提交以从源项目中引入最新的 HEAD。
我们不喜欢这样，因为它使我们的历史非线性并且我们将有许多“无用”的合并提交。
我们的替代想法是：
历史是线性的，只是对分叉的提交者进行了一些协调。
这种方法有什么问题？
你从这里开始（U是上游，Y是你的）：
UB--U1--U2
\
Y1--Y2
现在你做一个变基（和push -f）：
UB--U1--U2--Y1'--Y2'
现在您的其他团队成员可以pull --rebase：
UB--U1--U2--Y1'--Y2'--Y1''--Y2''
正如 robinst 指出的那样——如果你必须解决冲突，git 不会注意到 repo 中已经有Y1andY2的版本，而只是再次变基（可能也会产生一些丑陋的冲突）。
我只是建议进行合并（您可以使用 来查看您的线性历史记录
git log --no-merges）。如果您真的想尝试变基方式，可以执行以下操作：
你跑：
git fetch --all
git branch rebase_base master
git push origin rebase_base
git rebase upstream/master
git push -f origin master
然后其他人运行：
git fetch origin
git rebase --onto origin/master origin/rebase_base master
看看git help rebase为什么会这样;)。基本上你是在告诉 git 直到你已经做了 rebase ( rebase_base) 的哪个提交，所以它不会 rebase 不需要它的东西。
你不需要git push -f。变基和合并（分别通过和合并git pull --rebase）git pull是两种选择，您可以遵循其中任何一种来使您的分支与上游保持同步。
做git pull --rebase，解决冲突，如果有的话，享受“无用的”合并提交免费历史，然后做git push
如果您在第 2 步中执行变基时必须解决冲突，第 4 步可能对其他人没有问题。
原因是 Git 通过通过补丁 ID 比较提交来检测是否已经应用了提交（参见git patch-id）。由于进行更改以解决冲突，补丁 ID 可能会更改。
因此其他人可能需要手动工作，例如重置和挑选本地更改。
简单地说， git push -f 到你自己的分支并没有什么坏处。当您必须与其他开发人员协调时，就会发生不好的部分。除非每个人都在你进行力推的确切时刻进行沟通，否则它可能会变得复杂。为了避免复杂化，每个开发人员都必须停止他们正在做的工作以适应强制推动。它扰乱了工作流程，最终花费了不必要的时间和精力。
分布式版本控制系统的好处是您无需要求开发人员停止工作以适应编辑！在过去，当开发人员（a）签出文件时，VCS 系统将获得对该文件的悲观锁定，而其他开发人员（b）将不得不争先恐后地寻找第一个开发人员（a）签出文件并要求开发人员（a）签入文件，以便开发人员（b）可以编辑文件。但我跑题了。
回到主题，我认为您会从使用主题分支工作流中受益。在你的分叉中设置master分支以跟踪你分叉的原始工作。Master 包含原始项目的所有工作。
当您的团队开发新功能时，他们将需要在某处合并更改。创建一个名为development或任何您选择的新远程分支的情况并不少见，以便团队可以推送/拉取他们的更改。这个新的远程分支实际上是trunk您团队的分支。
需要有人负责将原始项目的更改合并master到分叉项目的development分支中，但这比要求每个人都适应一个强制推送到主干要容易得多。您还需要为分叉项目的主分支和开发分支设置策略。此工作流程允许开发人员在不中断他们自己的工作流程的情况下提取/合并分叉的存储库。