我一直在阅读 git merge 和 git rebase 操作的工作方式，我想我对这些差异有了非常基本的了解。我已经看过图表了:-)尽管如此，我仍然不清楚两者中最好用的是什么才能用于我目前的工作流程。
我的工作是使用 perforce 作为SCM系统，但我在本地使用 git 来跟踪本地更改，进行重构以及其他一些很酷的工作git可以带来的东西。我知道已经存在一个工具来帮助设备使用git和perforce（ex p4-git），但我不一定想要/需要这些开销，所以我试图让事情变得尽可能简单。以下是我当前创建本地git分支并最终集成到我们的主要perforce仓库的工作流程的简要说明：
我有一个主 git分支，每夜p4同步到我们的代码库。在perforce同步之后，我将所有更改提交到主分支。实际上，我的 master git分支实际上是提交给perforce主线的最新代码的快照。
对于我正在进行的本地更改，我总是首先创建一个 git branch ，并在处理更改时 checkout 这个分支。
我偶尔会将我的分支更新为 master 中的最新版本。到目前为止，我刚刚发布了一个 git merge master 命令来做到这一点，而且它一直很好。
当我准备好承诺实际的perforce仓库时，我将我的分支合并回我的主分支，检查主并发出 git merge BRANCH 然后使用常规perforce命令提交
鉴于我的工作流程，我是否应该在步骤＃3中使用 git rebase master 命令而不是 git merge master ？根据我对 rebase 命令的理解，只有当我们的 perforce mainline （远程库）分支时，才需要这样做，我想创建一个新的 master 基于此分支（比如我称之为master-newbranch）并将我的更改应用于此新分支。我需要首先 rebase 离开这个分支吗？
一般来说，我目前的工作流程是否有意义，或者我已经养成了一些不良习惯？
答案 0 :(得分：1)
在这种情况下，你不应该（必然）使用rebase而不是合并。请记住，rebase基本上会重写您的历史记录。它有助于清理多个分支并提供更线性的历史记录，但从您的用例中，您不会通过使用rebase获得任何东西。您描述的行为是一个正常的git工作流，其合并是为此而设计的。
关于rebase的一个棘手的问题是当你重新定位（重写历史）提交时，你已经推动了。这可能会导致与其他人合作时出现严重问题，但您正在使用perforce进行协作，因此您不太可能遇到此问题。
答案 1 :(得分：1)
我有相同的工作流程，更喜欢使用git rebase -i master。这使所有perforce resyncs保持在更改列表的底部。因此，我看来我检查了最新版本，并进行了大量的更改。此外，只有在重新同步后才会显示与分支相关的更改。看起来更直观，但听起来更像是风格而不是正确的东西。 〜奔
答案 2 :(得分：0)
Rebase正在重写您的历史记录。所以真的取决于你想如何保持你的历史。 Rebase使历史记录更加清晰。
历史记录显示了您项目中发生的事情。但是，你不必揭露你所做的一切。想象一下，你正在写一本书。您不必向用户显示您的写作历史记录，包括草稿版本。
在我的情况下，在合并master和branch时，我通常更喜欢rebase而不是merge。