Git pull.rebase这是一个可能危险的操作 [英] Git pull.rebase this is a possibly dangerous operation

问题描述

在 git-config 文档中有关pull.rebase的信息：

pull.rebase

当为true时，在获取分支顶部的rebase分支
而不是在运行
git pull时将默认分支与默认分支合并。请参阅branch..rebase，以
每分支为基础进行设置。

注意：这是一个可能危险的操作;除非
了解其含义（详情请参阅git-rebase（1））。

任何人都可以详细描述是什么>注意：这是一个可能危险的操作;除非你明白其含义，否则不要使用它（详情请参阅git-rebase（1）） mean

解决方案

假设您拥有这些Git仓库：

• 您的私人回购，坐在您的工作计算机上;
  
• 您的公共回购，您，托管在某处;
/ li>

• 一个主要的回购， origin ，这是主要的开发树。
  

你正在做一些事情，并提交了两个提交A和B.你将它们发布到你的公共回购站。同时， origin 有另一个提交Z.

  / -AB master，you / master 
 ooo 
 \ -Z origin / master 
  

<现在让我们说一个同事需要你的两个提交来开始一个新的功能。他将你的分支从你的公共仓库中提取出来，然后再进行一些提交。

  / -CDE同事/主人
 / -AB master，you / master 
 ooo 
 \ -Z origin / master 
  

您现在想要在 origin / master 之上添加您的两个完全测试的提交。你从 origin 获取并进行rebase（相当于 git pull --rebase 或 git pull ，并设置pull.rebase选项）。
创建两个新的提交。你推他们到你的公共回购和来源。让事情更加复杂的是，让我们假设一个新的提交F在此之后被推送到 origin 。

  / -ABCDE同事/主人
 ooo 
 \ -Z-A'-B'-F主人，您/主人，出身/主人
 
  / -CDE同事/ master 
 oooZ-A'-B'-F master，you / master，origin / master 
  
如果你没有告诉他，后来他会将他的分支合并回原点，并且历史记录如下所示： 
 
 
  / -ABCDE 
 ooo \ 
 \-Z-A'-B'-FM同事/主人，出身/主人
  
您有两次A和B提交，但名称不同。历史变得更难阅读，而你将陷入可怕的合并冲突。记住这个例子很简单。如果有数十人在项目上工作，并且 origin 正在快速移动，那么历史很快就会变成一团糟。
 
 
 
如果只有一个同事，那可能很好。但是如果你不能确切地知道谁从你身上拉下来，你无法知道你要警告谁。特别是在开源开发中。
 
 
 
主要规则是：不要重新提交已发布的提交。如果A和B只出现在您的私人回购协议中，那么重新贴牌是很好的，并且可能是最好的做法，因为它使历史变得更简单和有意义。分支历史只有在分支有充分的理由存在时才有意义（例如特色分支）。
 
In the git-config documentation the information about pull.rebase:

  
pull.rebase  
  
  
When true, rebase branches on top of the fetched branch,
  instead of merging the default branch from the default remote when
  "git pull" is run. See "branch..rebase" for setting this on a
  per-branch basis.
  
  
NOTE: this is a possibly dangerous operation; do not use it unless you
  understand the implications (see git-rebase(1) for details).
Could anybody describe in details what does "NOTE: this is a possibly dangerous operation; do not use it unless you understand the implications (see git-rebase(1) for details)" mean?
解决方案
Let's say you have these Git repositories: 


your private repo, sitting on your work computer;
your public repo, you, hosted somewhere;
a main repo, origin, which is the main development tree.


You're working on something and made two commits A and B. You published them to your public repo. In the same time, origin has one other commit Z.
     /-A-B master, you/master
o-o-o
     \-Z origin/master
Now let's say one colleague needs your two commits to begin a new feature. He pulls your branch from your public repo and makes some commits on top of that.
          /-C-D-E colleague/master
     /-A-B master, you/master
o-o-o
     \-Z origin/master
You now want to add your two, completely tested, commits on top of origin/master. You fetch from origin and make a rebase (which is equivalent to git pull --rebase or git pull with the pull.rebase option set).
That creates two new commits. You push them to your public repo and to origin. To complicate things further, let's say a new commit F is pushed to origin after that.
     /-A-B-C-D-E colleague/master
o-o-o
     \-Z-A'-B'-F master, you/master, origin/master
Now the problem is that your colleague has some work based on two "deprecated" commits, and to avoid further complications (conflicts when merging, messing up history) he must rebase his branch on top of B' (let's say he doesn't want F). You need to tell him about that, or else maybe he won't notice what you've done.
            /-C-D-E colleague/master
o-o-o-Z-A'-B'-F master, you/master, origin/master
If you didn't tell him, later he would merge his branch back into origin, and the history would look like this:
     /-A-B-C-D-E
o-o-o           \
     \-Z-A'-B'-F-M colleague/master, origin/master
You have twice the A and B commits, though with different names. The history becomes harder to read, and you will run into awful merging conflicts. And remember this example is quite simple. If there are tens of people working on the project, and origin is moving fast, the history will soon become a complete mess.

If it's only one colleague it's probably fine. But if you can't know exactly who pulled from you, you can't know who you have to warn. It's especially true in open source development.

The main rule is: don't rebase commits you've already published. If A and B were only in your private repo, rebasing is fine and is probably the best thing to do, because it makes the history simpler and meaningful. A diverging history is only meaningful when the branch has a good reason to exist (e.g. a feature branch).

                        
这篇关于Git pull.rebase这是一个可能危险的操作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！