git-pull*after*git-rebase？

我有一个功能分支和一个主分支

主分支已经进化，我的意思是让这些更新尽可能少地偏离主分支

所以我在两个分支中

git-pull

，

git-checkout-feature/branch

，最后

git-rebase-master

现在，我希望一切都能顺利进行，或者出现冲突，我需要在继续重新设置基础之前解决这些冲突，直到所有主提交成功地重新应用到功能分支上

现在，我不明白我的情况到底发生了什么：

$>git rebase master
First, rewinding head to replay your work on top of it...
Applying: myFirstCommitDoneOnTheBranch
Applying: myOtherCommitDoneOnTheBranch
$>git status
On branch feature/branch
Your branch and 'origin/feature/feature' have diverged,
and have 27 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
nothing to commit, working tree clean
$>git pull
*load of conflicts*

现在，就我所能理解的，他在拉后的冲突负荷；我不明白拉的必要性。从逻辑上讲，它应该在分支时回滚到master，保存分支上的提交，转发到master上的最新提交，然后应用保存的提交

---

我不明白

应用

消息指的是什么：什么在哪个版本上应用提交？

该

有27个和2个不同的提交，每个
告诉您现在有27个来自
主机的新提交
和分支中的2个新提交，它们在
源代码/
中不存在

由于重新基址对
origin/
进行了大量更改，因此它不再与
origin/
具有公共基址。因此，您不希望在重基后从
原点/
提取更改，因为正如您所看到的，所有H***都会松开

如果您知道您的本地分支机构需要在
origin/
中进行更改，请在重新设置基础之前将这些更改提取出来

如果您确定自上次推送（如果这是您自己的功能分支，这是一个安全的赌注）以来没有人更改
原点
，则可以使用
push--force
将它们再次同步。然后
origin/
将再次与您的本地分支具有相同的基础，并且该基础将包含所有最新的
master
更改。
如果
master
和
feature/branch
的远程版本分别是最新的，则只需重置您的本地功能分支即可

git checkout feature/branch
git fetch origin feature/branch
git reset --hard origin/feature/branch

然后，如果要在
主分支中引入更改

git rebase origin/master

tl；dr您应该在
master
的基础上更新
master
和
feature
之前，使用
git pull
和
git pull--rebase
更新
master
和
功能在将
功能
重新设置在
主功能
上的分支基础后，无需执行
git pull

在当前工作流中，
git status
的原因告诉您：

您的分支和“起源/特征”已发生分歧，
和分别有27个和2个不同的提交

这是因为您的rebase
功能
分支现在有25个新提交，这些提交无法从
源代码/功能
访问（因为它们来自
主代码
上的rebase），另外还有2个提交，这些提交可以从
源代码/功能
访问，但具有不同的提交ID。这些提交包含相同的更改（即，它们是补丁等效的），但它们具有不同的SHA-1哈希值，因为它们基于
origin/feature
中的不同提交，而不是您在本地存储库中重新设置它们的提交

这里有一个例子。在
master
上执行
git pull
之前，假设这是您的历史记录：

A - B - C (master)
         \
          D - E (feature)

在
git pull
之后，
master
获得提交
F
：

A - B - C - F (master, origin/master)
         \
          D - E (feature)

此时，您可以在
主控
上重新设置
功能
，该功能适用于
D
和
E
：

A - B - C - F (master, origin/master)
             \
              D - E (feature)

同时，远程分支
origin/feature
仍然基于提交
C
：

A - B - C - F (master, origin/master)
         \   \
          \   D' - E' (feature)
           \
             D - E (origin/feature)

如果您在
feature
上执行
git status
，git将告诉您，您的
feature
分支已分别从
源代码/特征代码
分支出3（
F
，
D'
，
E'
）和2（
D
，
E
）提交

请注意，
D'
和
E'
包含与
D
和
E
相同的更改，但具有不同的提交ID，因为它们已在
F
的顶部重新设置

解决方案是在
master
和
feature
上执行
git pull
，然后在
master
上重新设置
feature
的基址。但是，由于您可能在
功能
上提交了尚未推送到
原点
，因此您需要执行以下操作：

git checkout feature && git pull --rebase

避免在
源/功能
和本地
功能
之间创建合并提交

重新定基的后果的最新情况：
在阳光下，我在分叉的树枝上展开。
git status
报告在重新基址后
feature
和
origin/feature
出现分歧的原因是，重新基址为
feature
带来了新的提交，加上它重写了以前推送到
origin/feature
的提交

考虑拉动后但重新基准前的情况：

A - B - C - F (master)
         \
          D - E (feature, origin/feature)

C' (feature)
B'
A'
* (master, origin/master)
*
*
| C (origin/feature)
| B
| A
|/
* some base commit

此时，
feature
和
origin/feature
指向相同的提交
E
——换句话说，它们处于“同步”状态。在将
功能
重定为
主功能
的基础上，历史将如下所示：

A - B - C - F (master)
         \   \
          \   D' - E' (feature)
           \
             D - E (origin/feature)

A - B - C - F (master)
         \   
          D - E - F' (feature)
              ^
             (origin/feature)

如您所见，
feature
和
origin/feature
已经分开，它们的共同祖先是commit
C
。这是因为
feature
现在包含了
master
加上
D'
和
E'
（读作“D prime”和“E prime”）的新提交
F
和
E
，它们是应用于
F
之上的提交。即使它们包含相同的更改，Git也会考虑
C' (feature)
B'
A'
* (master, origin/master)
*
*
| C (origin/feature)
| B
| A
|/
* some base commit

* (feature)
|\
C'|
B'|
A'|
* | (master, origin/master)
* |
* |
| C (origin/feature)
| B
| A
|/
* some base commit