本文介绍了Git推送到refs / remotes / mine / master的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 29岁程序员，3月因学历无情被辞！ 我正在跟踪远程存储库，即我有 refs / remotes / joe / master 。 我知道想尽快将joe的更改加入我的仓库。 我不想使用 fetch ，因为我可能不在电脑在他提交时。所以我告诉他：我可能会出去购物，所以请把你的改变推到 refs / remotes / joe / master 。 原因I我希望他的回复能够尽快完成，因为他在晚上关掉了电脑，所以当我从购物中回来时，我无法获取他的更改。 我知道joe应该设置一个裸露的公共存储库，但这是一个开销。 推荐给 refs / remotes / joes / master 在这种情况下可以做的事情？ 解决方案保持多个（非裸）Git仓库同步的最好/最简单的方法提出用更新后的钩子来处理这种贡献。不过，有一个更直接的解决方案： OP zedoo 评论，（由Git的维护人Junio C Hamano在2007年写的）详细信息： （这是一个很棒的例子） 适用于非裸回购的情况） 当您推入底层时，如何拆分 HEAD 分支，并使 HEAD 一个非symref？ 我不认为需要任何复杂的东西，我认为有人提到了一个很好的例子，它是一个防火墙主机，只能被推入。 在这个例子中，尽管他知道自己可以在理想世界中反向获取，但网络配置并不允许他这样做，因此需要按。 为了处理这种情况，在非裸仓库之间进行推送的人可能会忘记推入分支机构。它们可以将它们的推送作为他们希望能够执行的真正的镜像镜像 。 b 举例说明： 回购 A 只能推入，如果您 可以从回购中获取 B $ b $同像这样： [remoteB] fetch = refs / heads / *： refs / remotes / B / * $ git push A [remoteA] push = refs / heads / *：refs / remotes / B / * $ git merge remotes / B / master gitster $ git push kernel-org-private gitster $ ssh kernel.org kernel.org $ git merge origin kernel.org $ Meta / Doit - 迂腐& kernel.org $ exit ...去喝我的茶...... 其中 gitster 是我的私人开发机器 kernel.org 是友好的k.org伙伴向我提供的机器 Meta 是我的' todo '分支和 Doit 是构建所有四个公共分支的脚本。 ' master '在我的 kernel.org 存储库中签出，并且从我的私有机器推送完成仍然使用非分离的远程布局）： 推送：refs / heads / master： refs / heads / origin Push：refs / heads / next：refs / heads / next Push：+ refs / heads / pu：refs / heads / pu Push：refs / heads / maint：refs / heads / maint I am tracking a remote repository, i.e. I have refs/remotes/joe/master.I know would like to get joe's changes as soon as possible into my repository.I don't want to use fetch, because I might not be at the computer when he commits. So I tell him: I might be out for shopping, so please just push your changes to refs/remotes/joe/master.The reason I want his changes asap in my repo is that he turns off his computer in the evening, so I wouldn't be able to fetch his changes when I come back from shopping.I know that joe should just setup a bare, public repository, but this is sort of an overhead.Is pushing to refs/remotes/joes/master an okay thing to do in such a case? 解决方案 "best/simplest way to keep multiple (non-bare) Git repos in sync" proposes to deal with that kind of contribution with a post-update hook.However, there is a more straightforward solution:As The OP zedoo comments, the thread on git push to a non-bare repo (written by Git maintainer Junio C Hamano, back in 2007) details:(and it is a great example of a case where it is appropriate to push to a non-bare repo)What about splitting HEAD when you push to the underlying branch, and making HEAD a non-symref? I do not think any of the complication is needed, and I think somebody mentioned a good example, which is a firewalled host that can only be pushed into. In that example, even though he knows he could fetch in reverse direction in the ideal world, the network configuration does not let him do so, hence need for a push. To deal with that sanely, people who push between non bare repositories can just forget about pushing into branch heads. Instead, they can arrange their pushes to be a true mirror image of their fetch that they wish could do. To illustrate: On repo A that can only be pushed into, if you could fetch from repo B, you would:$ git fetch B[remote "B"] fetch = refs/heads/*:refs/remotes/B/*$ git push A[remote "A"] push = refs/heads/*:refs/remotes/B/*$ git merge remotes/B/mastergitster$ git push kernel-org-privategitster$ ssh kernel.orgkernel.org$ git merge originkernel.org$ Meta/Doit -pedantic &kernel.org$ exit... go drink my tea ...Push: refs/heads/master:refs/heads/originPush: refs/heads/next:refs/heads/nextPush: +refs/heads/pu:refs/heads/puPush: refs/heads/maint:refs/heads/maint 这篇关于Git推送到refs / remotes / mine / master的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！
