我正在尝试找出与多个分支和PR可能相互依赖的最佳工作流程。我只想知道最佳实践是什么，特别是在这种情况下围绕变基，以免git陷入不良状态。到目前为止，我已经或多或少做了一些描述的场景。请让我知道什么是更好的做法：
我在github上工作，在github上有一个原始主机远程仓库，我也有自己的用户远程仓库。我将用户推送到用户远程仓库，并将PR放入源主远程仓库。
git checkout master
git checkout -b branch_first
.. do some work ...
git commit
git push remote
# Make a PR on github for branch_first, to merge it into the origin master branch
# While I wait for comments/review on branch_first, start to
# Work on branch_second
git checkout -b branch_second # This branch is based off first
.. do some work ...
git commit
git push remote
# Make a PR on github for branch_second, to merge it into the origin master branch
# Got some review comments, checkout branch_first and make some changes
git checkout branch_first
.. do some work ...
git commit
git push remote # Possibly repeat this, or ask the committer to merge when done.
现在，这似乎大部分都可行，但是在重新定基础时，我似乎经常陷入困境。
有时，您需要压缩fixup提交以保持PR整洁并易于查看。所以我在branch_second上运行了这样的内容。
rebase -i HEAD~10
# change commits to fixup or squash and save.
执行此操作时，我遇到了奇怪的行为，需要修复与我未编辑的文件的合并冲突。一位同行告诉我，这可能会占用之前的所有10次提交，并找到一个共同的祖先来移动branch_second指针，从而引起诸如此类的怪异问题。
有时候，我需要将在branch_first代码审查期间更改的代码文件保存到branch_second
rebase branch_first
据我了解，这可能一直无法正常工作吗？我认为有时候这会使我陷入困境。一些同行告诉我，这可能更适合在branch_second上运行
git rebase --onto master branch_first branch_second
有时，我需要再次从原始主机获取文件。所以我在branch_first或branch_second上运行它。
git fetch origin master
git rebase origin/master
有时，当我运行rebase命令时，我失去了祖先，我最想要的是提交，但是我在git日志历史记录中没有看到期望的提交。
答案 0 :(得分：0)
git rebase -i HEAD~10在branch_second上将导致branch_first和branch_second偏离。这可能会导致您在branch_second的提交历史记录中看不到branch_first。最好只将branch_second基准化为branch_first。
rebase branch_first在branch_second上时，要将提交从branch_first PR提交到branch_second中，是一种非常常见的工作流程，实际上不应引起任何奇怪的错误。
git rebase origin/master在branch_second上时，基本上会复制branch_second上所有提交的副本（具有不同的提交ID），直到branch_second和origin / master的共同祖先为止。由于branch_first仍与旧的提交（刚刚复制的）相关联，因此在查看此变基之后的branch_second的历史记录时，它不会显示。
我建议阅读this文章，以更直观地了解git rebase的作用。