Git：安全地推送非裸存储库 [英] Git: making pushes to non-bare repositories safe
问题描述
我可以使用git专家的一些指导，关于如何将安全操作推送到非裸仓库。基本上我有一个关于如何做到这一点的计划，并且可以使用一些关于计划是否理智的建议：）
通常当你推到一个非裸git仓库，其工作副本和索引不会更新。正如我发现的那样，如果您忘记手动更新它们，可能会导致严重问题！
在我们的小组中，我们有一些中央存储库，关闭并推回，但许多人也希望能够克隆他们的克隆并按需要以真正的分布式方式在它们之间推/拉。为了保证安全，我想确保通过clone或init创建的每个存储库都有一个自动安装的post-receive hook，它将在推送操作后更新工作目录和索引以与新的HEAD。
我发现我可以通过在hooks子目录中使用post-receive钩子创建一个模板目录，然后让我的组中的每个人做一个：
git config --global init.templatedir / path / to / template / dir
目前我的post-receive钩子看起来像这样：
export GIT_WORK_TREE = ..
git checkout -f HEAD
SEEMS根据需要工作，但我对checkout命令有一些不确定性。为了使工作目录和索引与HEAD中的状态同步，git checkout -f HEAD和git reset --hard HEAD是否相同？
我问，因为虽然我知道git reset --hard HEAD会做我想做的事情，在post-receive hook中使用它可以大大减缓我的测试中的push操作（它似乎对所有文件进行了全新检查，无论在工作目录中文件是否脏或干净）。 git checkout -f HEADSEEMS可以更快地完成同样的任务（让我有一个干净的工作目录和索引与HEAD同步），但由于checkout命令可以在飞行中执行，我有点紧张与未提交的工作目录更改合并。这个命令真的会给我一个工作目录吗？在所有情况下（包括，例如，文件删除，重命名等），在HEAD中的索引是否完全匹配？
在此先感谢您的任何建议！ p>
我可能误解了这个问题。你真的想要设置它，这样任何人都可以推送到开发人员的工作目录，而他正在进行未确定的更改吗？这不能被任何一个词的安全。
大多数人做的是有他们正常的工作目录，这是私人的，并且做一个裸露的将其克隆到同一磁盘上的公共库存中，并共享该存储库。这使用硬链接，所以你几乎不使用任何额外的空间。您将更改推送给您的同事的公开裸回购，并在他准备好接收更改时进入他的工作目录。或者，您将更改推送至您的公开裸回购，并且您的同事在准备就绪时从该处撤离。推送到非裸仓库的原因很难建立。
I could use some guidance from the git experts out there regarding making push operations to non-bare repositories safe. Basically I have a plan about how to do this, and could use some advice about whether the plan is sane or not :)
Normally when you push to a non-bare repository in git, its working copy and index are not updated. As I've discovered, this can cause serious problems if you forget to later update them manually!
In our group, we have a few "central" repositories that people clone off of and push back to, but many people also want to be able to make clones of their clones and push/pull between them as needed in true distributed fashion. In order to make this safe, I want to ensure that every repository created via either "clone" or "init" has a post-receive hook automatically installed that will update the working directory and index after a push operation to be in sync with the new HEAD.
I've found that I can make this happen by creating a template directory with my post-receive hook in a hooks subdirectory, then having everyone in my group do a:
git config --global init.templatedir /path/to/template/dir
Currently my post-receive hook looks like this:
export GIT_WORK_TREE=..
git checkout -f HEAD
This SEEMS to work as desired, but I have some uncertainty about the checkout command. For the purposes of syncing the working directory and index with the state in HEAD, are "git checkout -f HEAD" and "git reset --hard HEAD" equivalent?
I ask because although I know that "git reset --hard HEAD" will do what I want, using it in a post-receive hook slows down push operations considerably in my testing (it seems to do a fresh check out of all files, regardless of whether a file is dirty or clean in the working dir). "git checkout -f HEAD" SEEMS to do the same thing much faster (get me a clean working directory and index in sync with HEAD), but I am a little nervous given the propensity of the checkout command to do on-the-fly merges with uncommitted working directory changes. Will this command really give me a working dir & index that exactly match the state in HEAD in all cases (including, eg., file deletions, renames, etc.)?
Thanks in advance for any advice!
I might have misunderstood the problem. Do you really want to set it up so anyone can push to a developer's working directory while he has uncommitted changes he's working on? That can't be made "safe" by any stretch of the word.
What most people do is have their normal working directory, which is private, and make a bare clone of that into a public repo on the same disk, and share that one. That uses hard links so you barely use any additional space. You push your changes to your colleague's public bare repo, and he does a pull into his working directory when he's ready to receive the changes. Alternately, you push your changes into your public bare repo, and your colleague pulls from there when he's ready. There's a reason pushing to non-bare repositories is difficult to set up.
这篇关于Git：安全地推送非裸存储库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
