本文探讨了在多人协作的git项目中，如何选择使用git rebase和merge。介绍了两者在不同场景下的应用，包括rebase如何保持提交历史的线性以及merge可能导致的分叉。通过模拟开发流程，解释了rebase后的merge步骤，以及解决冲突的过程。总结了merge和rebase的特点，帮助开发者更好地理解和选择合适的操作方式。
一、前提絮絮叨
多人在一个分支上合作时，很容易出现冲突，或者要先pull别人提交的代码，在本地合并、解决了冲突后才能提交，这样肯定是不方便的，所以一般多人完成的项目，都是多分支的。
其实 rebase 和 merge 都是用于将一个分支合并到另一个分支上，不同的是merge的提交会有分叉，rebase的提交历史是一条直线。本身rebase和merge就没有谁更优，只是使用场景不同。
- A 场景使用 merge,我们在各自的分支上完成后，checkout 到 master分支上，将自己的分支merge进去，如果有冲突，解决冲突后push ,使用场景是在
主分支上应用次分支的代码。 - B 场景使用rebase ,我们在自己的分支上完成后，rebase master，将master上别人已经合并的更改更新到自己的分支上，有冲突解决冲突，使用场景是
在此分支上应用主分支的代码。 - 上面的不同，我的权限不同，A场景中，我有master操作的权限，B场景中master分支下我没有merge的权限，权限高的人才能在审核后将次分支合并到master中，如果不rebase，没有冲突还好，有了冲突呢？所以要先rebase，在自己的分支上解决冲突，后merge到master后，一般次分支会被删除。
二、使用
为了模拟真实的使用，我会在github上新建一个项目。
最低0.47元/天 解锁文章
扫一扫
410
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
