3

我一直在阅读git merge和git rebase操作的工作原理，我认为我对这些差异有一个非常基本的了解。我已经看过这些图表 :-) 尽管如此，我仍然不清楚在我当前的工作流程中使用哪一个最好。

我的工作是使用perforce，因为它是 SCM 系统，但我在本地使用git来跟踪本地更改、进行重构以及 git 可以带来的其他一些很酷的东西。我知道已经存在一个工具来帮助使用 git 和 perforce（例如 p4-git），但我不一定想要/需要这种开销，所以我试图让事情尽可能简单。以下是我当前创建本地 git 分支并最终集成回我们的主要 perforce 仓库的工作流程的简要说明：

  1. 我有一个主git 分支，它每晚对我们的代码库进行 p4 同步。在 perforce 同步之后，我将所有更改提交到 master 分支。实际上，我的主git 分支本质上是提交到我们的 perforce 主线的最新代码的快照。

  2. 对于我正在进行的本地更改，我总是先创建一个git 分支，然后在进行更改时 签出这个分支。

  3. 时不时地我想将我的分支更新到master的最新版本。到目前为止，我刚刚发出git merge master命令来执行此操作，并且运行良好。

  4. 当我准备好提交到实际的 perforce 仓库时，我通过签出master并发出git merge BRANCH然后将我的分支合并回我的master分支，然后使用常规 perforce 命令提交

鉴于我的工作流程，我真的应该为 Step#3 使用git rebase master命令而不是git merge master吗？根据我对rebase命令的理解，这只有在我们的perforce 主线（远程仓库）被分支时才有必要，并且我想基于这个分支创建一个新的master（比如我称之为 master-newbranch）并应用我的更改到这个新的分支。我需要先从这个分支 变基吗？

总的来说，我目前的工作流程是否有意义，或者我已经养成了一些坏习惯？

4

3 回答 3

1

在这种情况下，您不应该（必然）使用 rebase 而不是 merge。请记住，rebase 本质上会重写您的历史记录。它在清理多个分支和提供更线性的历史记录方面很有用，但从您的用例来看，使用 rebase 并没有获得任何好处。您描述的行为是合并设计的正常 git 工作流程。

rebase 的棘手之处在于，当你对已经推送的提交进行 rebase（重写历史）时。这可能会在与他人协作时引起严重的头痛，但您正在使用 perforce 进行协作，因此您不太可能遇到此问题。

于 2011-01-07T18:19:46.923 回答
1

我有很多相同的工作流程，并且更喜欢使用 git rebase -i master。这会将所有 perforce 重新同步保留在更改列表的底部。因此，看来我检查了最新版本并进行了大量更改。此外，在重新同步后，只会显示与分支相关的更改。看起来更直观，但听起来更像是风格而不是正确性。〜本

于 2012-05-29T22:33:50.433 回答
0

Rebase 正在改写你的历史。所以真的取决于你想如何保留你的历史。Rebase 使历史更清晰。

历史显示您的项目中发生了什么。但是，您不必公开您所做的一切。想象你正在写一本书。您不必向用户展示您的写作历史，包括草稿版本。

就我而言，在将 master 合并到分支时，我通常更喜欢 rebase 而不是 merge。

于 2015-11-11T23:51:03.997 回答