无法在服务器上克隆文件夹，然后编辑和混帐推送？ [英] Cannot git clone a folder on a server and then edit and git push?

问题描述

之前我使用过Mercurial（Hg），可以在当地PC上做类似的事情：

  hg clone ssh：//[e-mail]/~/mysite.com 
  

然后会有本地文件夹名为 mysite.com ，我可以编辑它的内容，提交并说 hg push 并将其推送到服务器。当然，要让内容显示在工作目录中，我必须在 ssh 那里执行 hg up

使用Git，如果我这样做，在服务器上，执行

  git init 
 git add。 
 git commit -mok
  

并在本地PC上执行

  git clone ssh：//[e-mail]/~/mysite.com 
  

但是当我编辑一个文件和 git push ssh：//[e-mail]/~/mysite.com master ，那么它会拒绝它，因为它不是一个裸仓库。

有没有办法

1. 无论如何推动它，就像Hg？


2. 或者更好的是，推动它并自动做一些类似于 hg up - 它是 git checkout ，这样内容就立刻在mysite.com上可视化（使用任何网络浏览器） 。






---

更新：

似乎通常的做法是推动裸回购，但是我们不能使用裸回购并使上述（2）工作？如果这是一种实用的方式，那么我们不必坚持推动裸仓回购规则？

如果还有其他原因仍然推到裸露的回购和克隆在服务器上......然后：

如果服务器有目录例如〜/ mysite.com 和〜/ other_folder 等，那么 mysite.com 的回购应该在哪里？ mysite.com 是网站的内容，所以如果我把 index.html ，那么任何浏览器世界可以看到它。因此，创建一个裸回购，让它克隆〜/ mysite.com ，并在本地PC上使用 git push<路径>主; ssh<路径> cd到该文件夹​​，并执行git checkout更新内容在本地PC上自动由1行？该行是 git push ssh：//[e-mail]/~/mysite.com master; ssh ssh：//[e-mail]/~/mysite.com'git pull; git checkout'？

解决方案

我不知道人们为什么说它不被支持。推荐使用裸回购是推荐的做法，您可以通过将 receive.denyCurrentBranch 配置变量设置为'ignore'或'warn'通过错误信息（至少在1.7.1），当你尝试这样做时：

  remote：error：You可以将'receive.denyCurrentBranch'配置变量设置为
 remote：error：'ignore'或'warn'在远程存储库中允许推入
 remote：error：其当前分支;然而，除非你
 remote：error：安排它更新它的工作树来匹配你在
 remote：error：other方面推送的内容，否则不建议这样做。 
  

我会说你的工作流是在git push部署的地方，然后是远程端的硬重置正是这个配置变量创建的规则的例外。

另外，我没有亲自尝试过，但当前分支语言暗示你可以推送到不是 em>检出的远程分支，之后您可以将远程端快速合并到检出分支中。

I used Mercurial (Hg) before, and it was ok to do something like at the local PC:

hg clone ssh://[e-mail]/~/mysite.com

and then will have a local folder called mysite.com, and I can edit its content, commit, and say hg push and push it to the server. Of course, to have the content show up in the "working directory", I will have to ssh there and do an hg up.

With Git, if I do the same, at the server, do a

git init
git add .
git commit -m "ok"

and at the local PC, do a

git clone ssh://[e-mail]/~/mysite.com

but when I edit a file and git push ssh://[e-mail]/~/mysite.com master, then it will refuse it, because it is not a "bare repository".

Is there a way to

1. Push it anyway, like Hg?
2. Or, better yet, push it and have it automatically do something like hg up -- is it git checkout, so that the content is immediately visual on mysite.com (using any web browser anywhere).

---

Update:

It seems that the usual practice is to push to a bare repo... but can we not use a bare repo and make (2) above work? If it is a practical way, then we don't have to stick to the "push to bare repo" rule?

If there are other reason still to push to a bare repo and clone on the server... then:

if the server had directories such as ~/mysite.com and ~/other_folder etc, then where should the repo for mysite.com sit? mysite.com is the content of the website, so if I put an index.html, then any browser in the world can see it. So is it good to create a bare repo, let ~/mysite.com clone from it, and on the local PC, use git push <path> master; ssh <path> "cd to that folder and do git checkout to update the content" automatically by 1 line on the local PC? Will the line be git push ssh://[e-mail]/~/mysite.com master; ssh ssh://[e-mail]/~/mysite.com 'git pull; git checkout' ?

解决方案

I don't know why people are saying it's not supported. While pushing to a bare repo is the recommended practice, you can push to a non-bare by setting the receive.denyCurrentBranch config variable to 'ignore' or 'warn' as shown by the error message you get (at least on 1.7.1) when you try to do it:

remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.

I would say your workflow where you deploy with a git push followed by a hard reset on the remote side is precisely the exception to the rule for which this config variable was created.

Also, I haven't tried it personally, but the "current branch" language implies you can push to a remote branch that isn't checked out with no errors at all, after which you could do a fast-forward merge on the remote end into your checked out branch.

这篇关于无法在服务器上克隆文件夹，然后编辑和混帐推送？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！