Git for solo developer:merge vs rebase

Question

我是一名独立开发人员,我刚刚开始使用Git和私有BitBucket存储库.我不清楚的一点是Merge与Rebase.

我经常在台式机和笔记本电脑之间切换,并且一直使用BB来访问任一平台上的最新代码.我在加载最新提交的代码时一直在使用rebase,因为我认为它基本上清除了该平台(桌面或笔记本电脑)上的所有内容,并确保我拥有与BB相同的代码.那是对的吗？我什么时候应该使用merge这样的动作？

Answer 1

rebase和merge是将你的分支机构与另一个分支机构联系起来的不同策略.rebase将历史更改为两个分支开始分歧的点.另一方面,合并不会改变历史记录,可能会创建一个新的提交来显示两个分支的合并.

另请参阅有关rebase vs merge的文档.底线:使用rebase进行未按下的更改以创建整洁的历史记录; 否则使用合并.

更新: Linus在2009年写了这篇文章,看看他对git rebase和merge的建议.一句话:谨慎使用自己的私人物品.如果您的提交已被推送,则不再进行更改.

Answer 2

merge 顾名思义，它将两个开发分支合二为一。因此，假设您在提交 M1 处有一个主分支。然后，您在笔记本上工作并创建提交 N。您还可以在桌面上工作并创建提交 L：

   N
  /
M1-L

当您将 N 合并到 L 时，您将合并更改并获得新的提交 M2

   N
  / \
M1-L-M2

这会保留所有所做的更改，但是您会得到这些小的双路径，这可能会变得非常混乱，尤其是当您有很多路径时。

然后是变基。从相同的情况开始，变基会采用 N 或 L 提交之一，并假装它是在另一个提交之后进行的。这会导致一个新的提交 n'

M1-L-N'

N'和M2的内容相同，只是它们的历史看起来不同。

只要你一个人
就没关系。两种方式都会有当前状态

如果你在一个团队中，
差异就变得很重要：

当你的rebase分支已经被其他人拉取时，他可能会看到一些令人困惑的效果，因为他正在处理的分支突然包含完全不同的提交。
所以你不想对公开的东西进行变基。

另一方面，如果您有 10 名开发人员commit，并且merge历史会变得混乱，您可能更喜欢让开发人员在私有存储库上工作，然后rebase再到push集成分支。