Git对不包含新提交、不包含—；推动所需的力？

抱歉，如果此问题已被屏蔽，但我找不到屏蔽

我之所以来到这里，是因为我在工作中经历了一段非常痛苦的经历：我将master重新设置到错误的分支，然后执行了一个

git push

。。 这一刻似乎把事情搞得一团糟。现在，我正试图了解出了什么问题，以及为什么即使我没有使用

--force

标志，我的更改也会被推送

关于我们git分支策略的一些信息：

我们有不同的旧版本分支，我们只在这些分支上实施错误修复（分支v1.0、分支v2.0等），因为我们需要支持这些旧版本。然后是主分支，我们在其上实际实现了新特性

每当在旧版本的软件（f.e.branch v1.0）中发现bug时，我们就会从该版本中分支，为bug修复创建一个功能分支。然后，我们在v1.0分支的基础上重新设置此功能分支中的更改，然后在v1.0上进行快进合并。然后通过合并提交，我们将v1.0合并到v2.0，最后合并到master中，以便在产品的所有较新版本中也修复该缺陷。因此，在旧版本分支（f.e.branch v1.0）上进行错误修复/更改的流程如下所示：

FB -> v1.0 -> v2.0 -> master

从v1.0分支（创建要素分支）

做些改变

git rebase origin/v1.0

将要素分支的更改移动到最新的v1.0分支之上

git-push-f原点功能\u分支

快进合并功能分支到v1.0

通过合并提交将v1.0合并到v2.0

通过合并提交将v2.0合并到主机中

现在，在v1.0上所做的所有更改（仅限于错误修复）也都在软件的较新版本上

例如，对于软件v1.0上的错误修复，合并如下：

FB -> v1.0 -> v2.0 -> master

简而言之：v1.0是产品的最旧版本，v2.0将包含v1.0中的所有提交以及v2.0版本中的附加功能提交，master将包含v2.0中的所有提交以及用于产品新版本的附加功能提交

我做错了什么： 因此，正如我所说，当将错误修复程序合并回父分支时，我需要首先在父分支上重新设置更改的基础，因为在此期间父分支上可能有其他更改，然后快速合并回父分支

我正在开发一个只应该进入主分支的特性，所以我很自然地尝试将主分支重新设置为我的分支，以使我的更改在所有其他更改之上但我没有将主分支重定基址到我的功能分支，而是在v1.0分支上，将主分支重定基址到v1.0分支上（因此，不是我的功能分支）。。这导致master被重定基址到v1.0分支中。更糟糕的是，在没有检查的情况下，我也推了v1.0分支。。 结果：v1.0分支现在看起来与master完全一样。。不太好

现在我的问题是：我只是执行了一个错误的

git推送

，我没有强制推送v1.0分支。 我是如何理解重基的，就是当你做一个重基时，你重写了一个分支的历史，所以你需要使用git push-force，否则远程将不会接受你的更改。 在这种情况下，是否没有发生历史重写，因为master已经包含了v1.0分支的所有提交以及v1.0分支不包含的一系列附加提交

---

我真的很想正确地理解这一点，因为如果我需要进行强制推送，就会有更多的警铃开始为我响起，我想这不会发生。

基本上不会。当你在一个分支上重新设置基础时，你使用该（整个）分支作为根（起点）对于正在重定基础的提交

因此，您没有更改v1.0的现有历史记录，而只是添加到其中。不需要用力推

---

今后如何防止这种情况发生的最佳建议是避免重新定基期。从v1.0分支以创建修复程序。您已经在使用“合并”将更改导入到master中。

这有点长，因为您希望真正了解正在发生的事情，所以我将提供更多信息，而不仅仅是直接回答您的问题。但如果你没有从中得到任何东西：在推之前验证你的本地状态。（紧随其后的是：更加怀疑武力推动。）

---

人们习惯于认为“再基地”=“需要强制推动”，两者在某种程度上是相关的；但这不仅仅是重新定基调的行为造成了强制推进的需要。这是从分支的历史记录（比如branchX）中删除提交的行为，然后只有branchX需要强制推送

因此，考虑到这一点，让我们来浏览一下您的工作流程——首先是它的预期工作，然后是这个错误的发生。首先，你的回购协议可能看起来像

... O <--(origin/v1.0)(v1.0)
     \
   .. M -- x <--(origin/v2.0)(v2.0)
            \
         ... M -- x <--(origin/master)(master)

这里我们刚刚创建了一个新的ref，它指向与版本分支相同的commit

2） 做些改变

      A <--(feature_branch)
     /
... O <--(origin/v1.0)(v1.0)
     \
   .. M -- x <--(origin/v2.0)(v2.0)
            \
         ... M -- x <--(origin/master)(master)

那么这一步会给你

        A' <--(feature_branch)
       /
      B <--(origin/v1.0)
     /
    | A
    |/
... O <--(v1.0)
     \
   .. M -- x <--(origin/v2.0)(v2.0)
            \
         ... M -- x <--(origin/master)(master)

（这就是我在图中保留

A

的真正原因。）现在，如果没有

-f

标志，您将无法推送

feature\u branch

，因为推送将从远程设备对

feature\u branch

历史的理解中删除

A

但现在是一个很好的时间来提。。。基于我对步骤3的评论，您应该警惕将强制推送作为正常步骤的工作流。就像遥控器知道

A

是

feature\u分支

的一部分一样，如果任何其他开发人员有

fetch

ed或

pull

ed

功能，则必须告知历史已编辑
        A' <--(feature_branch)
       /
      B <--(origin/v1.0)
     /
    | A
    |/
... O <--(v1.0)
     \
   .. M -- x <--(origin/v2.0)(v2.0)
            \
         ... M -- x <--(origin/master)(master)

        A' <--(feature_branch)
       /
      B <--(origin/v1.0)
     /
    | A <--(origin/feature_branch)
    |/
... O <--(v1.0)
     \
   .. M -- x <--(origin/v2.0)(v2.0)
            \
         ... M -- x <--(origin/master)(master)

        A' <--(feature_branch)(origin/feature_branch)
       /
      B <--(origin/v1.0)
     /
... O <--(v1.0)
     \
   .. M -- x <--(origin/v2.0)(v2.0)
            \
         ... M -- x <--(origin/master)(master)

... O -- B -- A' <--(v1.0)(origin/v1.0)(feature_branch)(origin/feature_branch)
     \
   .. M -- x <--(origin/v2.0)(v2.0)
            \
         ... M -- x <--(origin/master)(master)

... O ----- B ---- A' <--(v1.0)(origin/v1.0)(feature_branch)(origin/feature_branch)
     \              \
   .. M -- x ------- M <--(or-igin/v2.0)(v2.0)
            \         \
         ... M -- x -- M <--(origin/master)(master)

... O ----- B ---- A' <--(v1.0)(origin/v1.0)
     \              \
   .. M -- V ------- M <--(or-igin/v2.0)(v2.0)
            \         \
         ... M -- W -- M <--(origin/master)(master)

... O ----- B ---- A' <--(v1.0)(origin/v1.0)
     \              \
   .. M -- V ------- M <--(or-igin/v2.0)(v2.0)
            \         \
         ... M -- W -- M <--(origin/master)(master)
                        \
                         C -- D <--(feature2)

git rebase origin/v1.0

                     V' -- W' -- C' -- D' <--(feature)
                    /
... O ----- B ---- A' <--(v1.0)(origin/v1.0)
     \              \
   .. M -- V ------- M <--(or-igin/v2.0)(v2.0)
            \         \
         ... M -- W -- M <--(origin/master)(master)
                        \
                         C -- D

... O ----- B ---- A' <--(v1.0)(origin/v1.0)
     \              \
   .. M -- V ------- M <--(or-igin/v2.0)(v2.0)
            \         \
         ... M -- W -- M <--(origin/master)(master)
                        \
                         C -- D <--(feature2)

                     -------------------------------- M <--(v1.0)
                    /                                /
... O ----- B ---- A' <--(origin/v1.0)              |
     \              \                               |
   .. M -- V ------- M <--(origin/v2.0)(v2.0)       |
            \         \                             |
         ... M -- W -- M <--(origin/master)(master) |
                        \                          /
                         C ---------------------- D <--(feature2)

git pull --rebase