Git - 我的工作流程的合并与变基
我一直在阅读有关 git merge 和 git rebase 操作如何工作的内容，并且我认为我对这些差异有了非常基本的了解。我已经看过这些图表了:-)尽管如此，我仍然不清楚对于我当前的工作流程来说，这两者中哪一个是最好的。
我的工作是使用 perforce 作为 SCM 系统，但我在本地使用 git 来跟踪本地更改、进行重构以及 git 提供的其他一些很酷的东西可以带到餐桌上。我知道已经存在一个工具可以帮助使用 git 和 perforce （例如 p4-git），但我不一定想要/需要这种开销，所以我试图让事情尽可能简单。以下是我当前创建本地 git 分支并最终集成回我们的主要 perforce 仓库的工作流程的简要描述：
我有一个主 git 分支，它每晚进行一次 p4 同步< /strong> 到我们的代码库。在 perforce 同步之后，我将所有更改提交到 master 分支。实际上，我的 master git 分支本质上是提交到我们的 perforce 主线的最新代码的快照。
对于我正在处理的本地更改，我总是先创建一个 git 分支，然后在处理更改时签出该分支。
我时不时地想将我的分支更新到master的最新版本。到目前为止，我只是发出了一个 git merge master 命令来做到这一点，而且效果很好。
当我准备好提交到实际的 perforce 仓库时，我通过检查 master 并发出 将我的分支合并回我的 master 分支git merge BRANCH 然后使用常规 perforce 命令提交
考虑到我的工作流程，我真的应该使用 git rebase master 命令吗对于步骤#3 而不是git merge master？根据我对rebase命令的理解，只有当我们的perforce mainline（远程仓库）被分支，并且我想创建一个新的master时，这才是必要的 基于这个分支（假设我称之为 master-newbranch）并将我的更改应用到这个新分支。我需要先从这个分支变基吗？
总的来说，我当前的工作流程是否有意义，或者我是否已经养成了一些坏习惯？
I've been doing some reading on how both the git merge and git rebase operations work, and I think I have a very basic understanding of the differences. I've seen the diagrams :-) Despite that, I'm still not clear on what would be the best of the two to use for my current worflow.
My work is using perforce as it's SCM system, but I'm using git locally to keep track of local changes, do refactoring, and a bunch of other cool stuff that git can bring to bring to the table. I know there already exists a tool to help facility working with git and perforce (ex p4-git) but I don't necessarily want/need that overhead, so I'm trying to keep things as simple as possible. Here's a brief description of my current workflow for creating local git branches and eventually integrating back into our main perforce depot:
I have a master git branch, which does a nightly p4 sync to our codebase. After the perforce sync, I commit all changes to the master branch. In effect, my master git branch is essentially a snapshot of the latest code committed to our perforce mainline.
For local changes I'm working on, I always create a git branch first, and checkout this branch while working on the change.
Every now and then I want to update my branch to the latest from the master. Until now I've just been issuing a git merge master command to do that and it's been working out fine.
When I'm ready to commit to the actual perforce depot, I merge my branch back into my master branch, by checking out the master and issuing git merge BRANCH and then submit using regular perforce commands
Given my workflow, should I really be using a git rebase master command for Step#3 instead of a git merge master? From my understanding of the rebase command, this would only be necessary if say our perforce mainline (remote depot) was branched, and I wanted to create a new master based off this branch (say I call it master-newbranch) and apply my changes to this new branch. I would need to rebase off this branch first?
In general, does my current workflow make sense, or have I already picked up some bad habits?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在这种情况下，您不应该（必然）使用 rebase 而不是 merge。请记住，变基本质上是重写您的历史。它对于清理多个分支并提供更线性的历史记录很有用，但从您的用例来看，您并没有通过使用 rebase 获得任何东西。您所描述的行为是合并设计的正常 git 工作流程。
关于变基的棘手之处在于当您对已经推送的提交进行变基（重写历史记录）时。这可能会在与其他人协作时造成严重的麻烦，但您使用 perforce 进行协作，因此不太可能遇到此问题。
You should not (necessarily) be using rebase over merge in this case. Remember, rebase essentially re-writes your history. It's useful in cleaning up multiple branches and providing a more linear history, but from your use case you're not gaining anything by using rebase. The behavior you've described is a normal git workflow which merge was designed for.
The tricky thing about rebase is when you're rebasing (re-writing history) commits that you've already pushed. This can cause major headaches in collaboration with others, but you're using perforce for collaboration, so you're unlikely to run into this problem.
我有大致相同的工作流程，并且更喜欢使用 git rebase -i master。这会将所有 perforce 重新同步保留在更改列表的底部。因此，看来我查看了最新版本并进行了大量更改。重新同步后也仅显示与分支相关的更改。看起来更直观，但听起来更像是风格而不是正确性。 〜本
I have much the same workflow and prefer using git rebase -i master. This keeps all the perforce resyncs at the bottom of the change list. Thus it appears I checked out the latest version and made a ton of changes. Also only changes that pertain to the branch show up after a resync. Seems more intuitive, but it sounds more like style thing than a correctness thing. ~Ben
Rebase 正在改写你的历史。所以实际上取决于您想如何保留您的历史记录。总的来说，Rebase 使历史更加清晰。
历史记录显示了您的项目中发生的情况。但是，你不必揭露你所做的一切。想象一下你正在写一本书。您不必向用户展示您的写作历史记录（包括草稿版本）。
就我而言，当涉及到将 master 合并到分支时，我通常更喜欢 rebase 而不是 merge。
Rebase is rewriting your history. So really depends on how you want to keep your history. Rebase keeps history more clearer in general.
History shows what has happened in your project. But, you don't have to expose everything you have done. Imagine you are writing a book. You don't have to show users your writing history including draft versions.
In my case, I usually prefer rebase over merge when it comes to merging master to branches.