git推出2个遥控器的意外行为

Question

我有以下设置：

遥控：

origin，vijay

当地分支机构：

• 主
• 14.4_dev（通过执行git checkout origin / 14.4_dev -b 14.4_dev创建）
• 14.4_various_features（通过结帐vijay / 14.4_various_features -b 14.4_various_features创建）

当我在14.4_various_features分支上并执行git push时，它会将我的本地分支（例如master和14.4_dev）推送到vijay远程。这是预期的行为吗？

Answer 1

是。请参阅documentation of the push.default option，了解如何在仅运行git push时更改行为：

  

<强> push.default

     

定义在未明确给出refspec的情况下应采取的操作git push。不同的值非常适合特定的工作流程;例如，在纯粹的中央工作流程中（即获取源等于推送目的地），上游可能就是你想要的。可能的值有：

     

  

• nothing - 除非明确给出refspec，否则不要推送任何内容（错误输出）。这主要是针对那些希望通过始终明确避免错误的人。

  

• current - 推送当前分支以更新接收端具有相同名称的分支。适用于中央和非中央工作流程。

  

• upstream - 将当前分支推送回分支，该分支的更改通常集成到当前分支（称为@ {upstream}）。如果您要推送到通常从中拉出的相同存储库（即中央工作流程），此模式才有意义。

  

• simple - 在集中式工作流程中，如果上游分支的名称与本地分支的名称不同，就像上游一样增加安全性以拒绝推送。

       

  当推送到与您通常拉出的遥控器不同的遥控器时，请作为当前工作。这是最安全的选择，适合初学者。

  

• matching - 推送两端具有相同名称的所有分支。这使得您要推送的存储库记住将被推出的分支集合（例如，如果您总是在那里推送maint和master而没有其他分支，您推送的存储库将具有这两个分支，以及您的本地maint和master将被推到那里。

       

  要有效地使用此模式，您必须确保在运行git push之前准备推出所有要推出的分支，因为此模式的重点是允许您推送所有分支一个人去。如果您通常只在一个分支上完成工作并推出结果，而其他分支未完成，则此模式不适合您。此模式也不适合推入​​共享中央存储库，因为其他人可能会在那里添加新分支，或更新控制范围之外的现有分支的提示。

  

当你更喜欢matching或上游`时，很可能它当前设置为simple。

Answer 2

在.git/config文件中，您可以选择哪个是每个分支的默认远程。在这一点上，它可能会说

[branch "master"]
        remote = vijay
        merge = refs/heads/master
[branch "14.4_various_features"]
        remote = vijay
        merge = refs/heads/14.4_various_features
[branch "14.4_dev"]
        remote = origin
        merge = refs/heads/14.4_dev

根据您的全局git推送策略，您的推送可能会执行您所描述的内容。除非你的策略被设置为'current'，否则git会遍历你的分支，将它们中的每一个推送到各自远程控制器中的匹配分支。

Answer 3

并执行git push

这意味着“未提供refspec”。
关于这一点，在Git 2.26（2020年第一季度）中，请注意删除了“ explicitly”一词。

请参见commit 8b2a192的Jeff King (peff)（2020年1月29日）。
^{（由Junio C Hamano -- gitster --在commit 4cf7f48中合并，2020年2月12日）}

doc：从push.default描述中“明确给出”

^{签名人：杰夫·金}

push.default的文档中提到，如果未“明确给出” refspec，则使用该文件。
让我们在这里放弃“显式”的概​​念，因为它含糊不清，只需提及任何地方的refspec都足以覆盖它。

我也从下面“无”值的定义中删除了“明确给出”的提法。足够接近我们的澄清，很明显，我们在这里是指相同类型的“给定”。

为Junio C. Hamano explained：

我不确定故意设置remote.*.push配置的行为不应该算作对用户发出的对Git的明确请求。

立即遵循上述内容，对可能的值之一的说明如下：

• nothing-除非明确给出refspec，否则请勿推送任何内容（错误）。
  这主要是针对那些希望始终保持露骨的人避免犯错的人。

可能需要进行调整以保持整体一致。
如果我们决定说设置配置不算是明确的， 然后应将“除非明确给出refspec”更新为 匹配。
可能还有其他提到的“显式”需要调整（我没有寻找它，但是上面提到的是相邻的，我看不到）。

如果我们必须更改描述中的任何内容，我会说我们可以“显式”删除。
有多种方法可以从命令行，remote.*.push配置，在.git/remotes文件等中提供refspec。
如果是“如果从命令行提供refspec，则X发生，但是提供基于配置的refspec不会导致X发生”，这可能是发明和使用新的短语“隐式给定”的好理由，在本段中使用。
但是push.default仅在以下方法中的 none 用于提供 any refspec时才起作用，因此命令行来源的refspec和config之间没有什么区别我认为，在讨论此功能时会使用refspec。