13

对于某个远程，Fetch URL 和 Push URL 什么时候会不一样？

例如，当我git remote show central为名为 central 的远程运行时，输出如下所示：

* remote central
  Fetch URL: aoberoi@example.com:/home/aoberoi/Repositories/example.git
  Push  URL: aoberoi@example.com:/home/aoberoi/Repositories/example.git
  HEAD branch: master
  Remote branch:
    master tracked

我只是不明白为什么要从两个不同的 URL 获取和推送，这适用于什么类型的工作流？

4

2 回答 2

12

我不确定您的意思，因为您的示例包含 2 个相同的URL，但推送和拉取的 URL 可能会有所不同，因为：

  • 协议问题：参见Git 协议：url 会略有不同，因为并非每个协议都支持推送操作（例如 http，智能 http除外）
  • 中间存储库：您可以推送到不同的存储库，该存储库将成为真正的“中央”存储库和您的存储库之间的“中间人”。然后可以执行某些操作（例如通过接收后挂钩），然后如果这些操作（如“单元测试”、“静态代码分析”...... ) 成功通过。
    此类用法的示例，请参见：
    “您见过的最聪明的源存储库用法是什么？ ”。

话虽如此，Git 维护者Junio C Hamano ( ) 的commit 697f652 (Git 2.3.1+, Q1/Q2 2015 )确实提到：gitster

upstream尝试使用单个遥控器（例如'origin'）从一个地方（即）获取同时推送到另一个地方（即您的发布点）似乎是一个常见的错误。

这永远不会令人满意refs/remotes/origin/*，如果您考虑一下在这样一个世界中意味着什么，就很容易理解为什么。它根本无法反映现实。
如果它遵循您的上游状态，则它无法匹配您发布的内容，反之亦然。

文档并不清楚“ remote.<nick>.pushURL”和“ remote.<nick>.URL”是用来命名通过不同传输访问的同一个存储库，而不是两个单独的存储库。

于 2010-12-17T06:42:04.440 回答
0

我认为如果你想要一个“分期”回购贡献者将推送到，然后其他人会在审查和批准后将更改从那里推送到主回购，你可以使用它。因此，您将从主存储库中获取，然后推送到临时存储库。

于 2010-12-17T06:42:54.647 回答