Git“取URL”和“推送网址”,有什么区别? [英] Git "Fetch URL" and "Push URL", whats the difference?

查看:421
本文介绍了Git“取URL”和“推送网址”,有什么区别?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

什么时候获取URL和推送URL不会是相同的某个远程?



例如,当我运行 git远程显示中央的,输出如下:

  *远程中央
抓取网址:aoberoi@example.com:/home/aoberoi/Repositories/example.git
推送网址:aoberoi@example.com:/home/aoberoi/Repositories/example.git
HEAD分支:主人
远程分支:
跟踪的主人

我只是不明白为什么我会从两个不同的网址获取并推送到两个不同的网址,请问这种工作流程类型适用于哪种类型的网站? 我不确定是什么您的意思是,由于您的示例包含2个相同的网址,但推拉的URL可能因以下原因而不同:


  • 协议问题:请参阅 Git协议:网址将是略有不同,因为不是每个协议都支持推送操作(例如http,除非 smart http
  • 中间回购:您可以推送到不同的存储库,中间人之间的真正的中央回购和你的。然后可以执行某些操作(例如通过post-receive钩子),然后如果这些操作(如单元测试,静态代码分析等)将提交到那里的实际远程... )成功传递。

    例如,这样的用法,请参阅:

    什么是您见过的源代码库的最聪明的用法?





也就是说, commit 697f652 (Git 2.3.1+,2015年第1季度/第2季度)由Git维护者 Junio C Hamano( gitster 确实提到:


尝试使用单个遥控器似乎是一个常见的错误(例如'原始n')从一个地方(即上游),而推到另一个(即您的发布点)。



这绝对不会令人满意,并且很容易理解为什么如果您考虑在这样的世界中 refs / remotes / origin / * 会意味着什么。它从根本上不能反映现实。

如果它跟随你的上游状态,它不能匹配你已经发布的
,反之亦然。



文档不清楚 remote。< nick> .pushURL remote。< nick> .URL 是否存在通过不同的传输命名相同的存储库的命名不是两个独立的存储库


When would the Fetch URL and Push URL not be the same for a certain remote?

For example, when i run git remote show central for a remote named central, the output looks like:

* 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

I just don't see why I would be fetching from and pushing to two different URLs, what type of workflow is this intended for?

解决方案

I am not sure what you mean, since your example includes 2 identical URL, but URLS for push and pull can differ because of:

  • protocol issue: see Git protocols: the url will be slightly different because not every protocol supports push operations (http for instance, except in case of smart http)
  • intermediate repos: you can push to a different repository which will be the "middle man" between the true "central" repo and yours. Certains operations can then be performed (through a post-receive hook for instance), and the commit will then be pushed to the "actual" remote from there if those operations (like "unit testing", "static code analysis" ...) pass successfully.
    For instance of such a usage, see:
    "What is the cleverest use of source repository that you have ever seen?".

That being said, commit 697f652 (Git 2.3.1+, Q1/Q2 2015) by Git maintainer Junio C Hamano (gitster) do mention:

It seems to be a common mistake to try using a single remote (e.g. 'origin') to fetch from one place (i.e. upstream) while pushing to another (i.e. your publishing point).

That will never work satisfactorily, and it is easy to understand why if you think about what refs/remotes/origin/* would mean in such a world. It fundamentally cannot reflect the reality.
If it follows the state of your upstream, it cannot match what you have published, and vice versa.

The documentation wasn't clear that "remote.<nick>.pushURL" and "remote.<nick>.URL" are there to name the same repository accessed via different transports, not two separate repositories.

这篇关于Git“取URL”和“推送网址”,有什么区别?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆