我认为我们在一个分支中开发项目，完成后，将其重新设置为master分支，然后将其推送到存储库服务器。
如果我认为有误，请告诉我，并说明我们何时改用原产地/母公司
*更新：感谢您的回答，但您被误解了，我需要知道
git rebase master
和
git rebase origin/master
要比较git rebase master同git rebase origin/master。
你给的说法git rebase是什么样的git rebase文档调用上游。这不是一个很好的名字（在这种情况下，文档不是很好），但是答案就在那里。
要做的git rebase是复制一些提交。Git需要两条信息：它应该复制哪些提交？并将其复制到哪里？ 这个论点，即文档所说的上游，为这两个问题提供了答案。
要了解此复制过程，您需要绘制提交图的至少一部分，以便可以看到要复制哪些提交以及随后发生的情况。
绘制提交图有些棘手，尽管如果您练习一会儿就会很擅长。要绘制图形，您需要使用其父级链接查看提交。您可以使用git log --all --decorate --oneline --graph进行自己的图形绘制，也可以使用图形查看器（例如gitk或某些Git GUI）。（您不能使用GitHub的图形，因为它们包含错误的信息。）如果手动绘制它们，则使用白板或类似图形会很有帮助。
让我们在这里画一个快速的样本图。您自己的图可能会有所不同。
C4 <-- feature
/
...--C1--C2--C3 <-- master
\
C5--C6 <-- origin/master
这些代表提交。我们说每个提交都“指向”其父（上一个）提交。请注意，提交的父代总是来得更早，但是“更早”并不总是意味着很多。在这里，可能是从您的分支创建了您的分支，然后对它进行了一次提交。此后，您还运行了，它从Git所谓的名为的远程站点获取了两次提交。这两个提交现在在您的身上，但不在您的。Cnfeaturemastergit fetchoriginorigin/mastermaster
如果此时运行git checkout feature，然后git rebase masterGit会告诉您无事可做（Current branch feature is up to date）。如果您运行git rebase origin/master，它将执行某些操作。
关于原因的关键再次在文档中。通过使用gitrevisions文档中描述的两点符号选择要复制的提交， Rebase开始：
master..feature
（名称feature来自当前分支，即您已签出的分支；名称master来自您的参数to git rebase）。
这个两点符号的含义是：在提交图上，从feature其父级开始并向后工作，并将所有这些提交标记为绿色。然后，在同一图表上，从master其父节点开始并向后工作，并将所有这些提交标记为红色。
当我们用绘制的图形进行此操作时，我们先标记为C4绿色，然后标记为C3绿色，然后标记为C2绿色，依此类推。提交C5并且C6完全不会被标记。然后，我们将C3其标记为红色（这将覆盖其绿色），并标记为C2红色，依此类推。我们剩下的只是C4绿色。
这意味着git rebase master将要做的是复制提交C4。
现在，下一步是找出要复制的位置。答案是：紧接提交上游点之后。所以说：将提交C4复制到现在的位置。 这是没有意义的，所以git rebase说没事做。
如果您git rebase origin/master现在运行，Git将标记为C4绿色，然后标记为绿色，C3依此类推。然后它将标记为C6红色，C5红色，C3红色等。这为我们提供了要复制的提交列表，该列表再次只是commit C4。我们标记了更多提交，但最终复制的结果却是相同的。然后下一步是找出要复制的位置，这一次，它有所不同。
我们应该复制所有提交（所有提交），以便在origin/master指向1之后指向C6。因此，我们必须在其中复制提交C4。
复制提交的主要命令是git cherry-pick。因此，在内部，git rebase经常用于git cherry-pick进行复制。某些类型的rebase在内部使用不同的命令，但最终结果是相同的。无论如何，我们只能将其视为挑剔。
要进行复制，Git首先检出“之后”提交C6。这样做无需检出任何分支，而是使用Git所谓的“分离式HEAD”模式检出原始提交。如果在重新设置基准点期间出了点问题，您将处于这种“分离式HEAD”模式。没什么大不了的，如果一切正常，Git会立即退出该模式，但是值得记住。
无论如何，Git会“分离HEAD”并使其指向提交C6：
C4 <-- feature
/
...--C1--C2--C3 <-- master
\
C5--C6 <-- origin/master, HEAD (detached)
然后樱桃点C4复制。阅读该git cherry-pick文档的细节，但本质上，这个副本的改变你做，通过比较C4VS C3，然后作出新的承诺具有的副本提交信息也是如此。新副本位于HEAD提交之后，即C6，因此如下所示：
C4 <-- feature
/
...--C1--C2--C3 <-- master
\
C5--C6 <-- origin/master
\
C4A <-- HEAD (detached)
新的提交很像C4，但是有一个不同的父提交：它指向现有的提交C6，而不是C3。
现在，我们已经完成了所有拷贝，我们必须复制的提交，因此对于其最终的伎俩，git rebase使得分行的名称，我们都上，即feature，指向这最后提交其复制。换句话说，它重新连接了您的HEAD，但位于新的图形位置：
C4 [abandoned]
/
...--C1--C2--C3 <-- master
\
C5--C6 <-- origin/master
\
C4A <-- feature (HEAD)
C4？Git秘密地挂了一段时间，但它“已经消失了”。它没有可用来查找的名称。它不在您的任何分支上了！最终，保留它的东西（Git称为reflog条目）到期了，Git完全通过Git所谓的垃圾收集将其删除。不过，git rebase如果需要，您可以短时间“撤消” a 。
让我们回到原始图形，即在运行之前返回git rebase origin/master：
C4 <-- feature
/
...--C1--C2--C3 <-- master
\
C5--C6 <-- origin/master
如果在这一点上，你跑git checkout master，然后git merge origin/master-or git checkout master，然后git pull，它运行git merge于你，Git会动你的名字master在“快进”的操作：
C4 <-- feature
/
...--C1--C2--C3
\
C5--C6 <-- master (HEAD), origin/master
无需执行其他任何操作，因此Git所做的工作最少。就像一样，它也使名称master指向commit 。（我已经标有，因为我们做了一个高手来到这里。）C6origin/mastermasterHEADgit checkout
如果现在执行与以前相同的变基操作，则现在两个名称都指向，master并且origin/master指向相同的commit。因此，现在，git checkout feature将您的附件附加HEAD到上feature，git rebase master并git rebase origin/master会执行相同的操作。
记住，rebase操作使用上游参数来找出要复制的内容以及将复制的位置。这就是它使用此参数的全部内容，因此，如果两个不同的名称指向同一提交，则两个名称的“复制内容”和“复制位置”答案都相同。
当两个不同的名称指向不同的提交时，您将获得不同的结果。green-vs-red技巧可能（也可能不会—与其他图形一起尝试）意味着您复制了相同的提交，但根据定义，“复制位置”部分有所不同。
| 归档时间： |
|
| 查看次数： |
3956 次 |
| 最近记录： |