但同样，这仅适用于 私有 feature分支。如果你通过相同的功能分支(公共分支)与其他开发人员协作，那么你是 不被允许 重写其历史记录的。
将上游更改合并到功能分支中在 概念概述 部分中，我们了解了 feature 分支可以使用 git merge 或 git rebase 合并 master 分支的上游更改 。merge 是一个安全的方式，可以保留存 git repository 的整个历史记录，而 rebase 则是通过将 feature 分支移动到 master 顶端来创建线性历史记录。
这种使用 git rebase 类似于本地清理，但在此过程中它包含了那些来自 master 上游提交。
请记住，将当前提交 rebase 到远程 branch(非 master 分支)一样是合法的。当与另一个开发人员协作使用相同的功能并且你需要将他们的更改合并到你的 repository 时，就会发生这种情况。
例如，如果你和另一个名为 John 的开发人员添加了对 feature 分支的提交，在你 fetch (注意 fetch 并不会自动 merge )来自 John 的远程 feature分支后，你的 repository 可能如下所示：
你可以整合上来自上游的分叉：要么用 john/feature merge 本地 feature ，要么 rebase 本地feature 到john/feature 的顶部。
请注意，此 rebase 不违反 Rebase 黄金规则，因为只有你的本地 feature 提交被移动， 之前的所有内容都不会受到影响。这就像是说 "将我的更改添加到 John 已经完成的工作中"。在大多数情况下，这比通过合并提交与远程分支同步更直观。
默认情况下，使用 git pull 命令执行合并，但你可以通过向其传递 --rebase 选项来强制它将远程分支 以 rebase 方式集成。
git pull --rebase 使用 Pull 请求 Review Feature如果你在代码审查过程中使用 pull 请求，在使用了 pull 请求之后你应该避免使用 git rebase 。一旦你发出 pull 请求，其他开发人员就会查看你的提交，这意味着它是一个 公共 分支。重写其历史记录将使 Git 和你的队友无法跟踪添加到该功能的任何后续提交。
其他开发人员的任何更改都需要合并 git merge 而不是 git rebase。
因此，在提交拉取请求之前，通常使用交互式 rebase 清理代码通常是个好的办法。注意使用顺序
集成已批准的功能在你的团队批准某项 feature 后，你可以选择将该功能 rebase 到 master 分支的顶端，然后git merge再将该功能集成到主代码库中。
这与将上游更改合并到 feature 分支中的情况类似，但由于你不允许在 master 分支中重写提交，因此你必须最终使用 git merge 该功能进行集成。但是，通过在 merge 之前执行 rebase，你可以确保会以 fast-forward 方式 merge，从而产生完美的线性历史记录。
如果您不熟悉 git rebase，可以随时在临时分支中执行 rebase。这样，如果你不小心弄乱了功能的历史记录，可以查看原始分支，然后重试。例如：
git checkout feature git checkout -b temporary-branch git rebase -i master # [Clean up the history] git checkout master git merge temporary-branch 总结如果你更喜欢没有不必要的干净的合并提交，线性历史记录，你就需要开始了解使用 rebase 功能。同时你应该会使用 git rebase 而不是 git merge 集成来自另一个分支的更改。
另一方面，如果你想保留项目的完整历史记录并避免重写公共提交的风险，你可以坚持下去git merge。这两种选择都是完全有效的，但至少现在你可以选择利用 git rebase 的好处 。
灵魂追问你有使用过 git rebase 吗？这样清晰的线形历史是不是可以尝试一下呢？
交互式 rebase 提交条目前的命令 fixup 等你能灵活使用吗
在 feature 分支上开发时，试试 git pull -rebase?
带着疑问去思考，然后串联，进而归纳总结，不断追问自己，进行自我辩证，像侦查嫌疑案件一样看待技术问题，漆黑的街道，你我一起寻找线索，你就是技术界大侦探福尔摩斯
提高效率工具