我在某个地方读过这样的设置会很好：
两个主要分支，每个服务器一个
向大师推送改变，让它活下去；
推送至dev/stage（或任何您称之为dev/stage的东西）会将更改发送至staging；
工作流：
-
从dev创建分支；
-
在本地工作，直到您准备好进行测试；
-
合并回dev；
-
推送到集线器，集线器将更改发送到dev/stating服务器。
一旦你准备好上线：
-
从dev合并到master，
-
然后将master推送到Hub，Hub将这些更改发送到实时服务器。
两个主要分支，每个服务器一个
所以我有一个分支"；生产"；关于"；webroot/myliveapp/"；另一分支"；开发"；关于"；webroot/devapp/"；
存储库应该在哪里
更新：
我的意思是：
我们将根据这个流程：
-
最优回购；
-
裸回购中枢；
-
克隆；
开发和生产分支应该属于一个存储库，对吧？
如果这是正确的，那么我们应该发出FIRST git init命令吗？关于我们的Prime回购？
因此，我们将拥有：
"webroot/myliveapp/"-生产分公司；
"webroot/devapp/"-发展分支；
"webroot/.git"-主存储库；
这有道理吗
还是Prime存储库应该与我们的生产分支机构位置相对应？
*注意：如果你需要一个关于我试图实现的工作流的上下文，这是一个吗：http://joemaller.com/990/a-web-focused-git-workflow/
感谢您对问题的更新，现在问题更清楚了。
我相信你的问题是基于对Git工作流程的误解；Git并不将目录等同于分支，而是将文件系统的视图等效于分支。这很强大，但很容易射中自己的脚。让我解释一下。
Git本身更像是一个数据库支持、版本不同的历史跟踪文件系统。它位于文件系统的"上方"，而不是"部分"。它不使用文件系统来表示分支，相反，当您签出不同的分支时，文件系统中的所有文件都将更改为该分支中的文件。您要求Git让您的文件系统代表该分支的另一个现实。
如果您在分支master上，并且它提交了一个文件root/foo.txt，并且您签出了分支experiment，它没有提交root/foo.txt，当您查找该文件时，您会发现该文件已经不存在了。它是master的一部分，而不是experiment，因此它不在您的文件系统中。这就是为什么Git在允许您切换分支之前，会非常挑剔您当前的分支是否被提交——如果您的文件系统上有Git不知道的未记录的更改，它会拒绝通过用不同的现实覆盖它们来破坏它们。你必须先介入，把事情做好。
因此，为了回答这个问题，不要为"myliveapp"one_answers"devapp"创建子目录——创建不同的分支。只需在"webroot"下创建一个代码库即可。然后，破解"不稳定"分支，像往常一样提交更改。然后，您可以通过切换到"devapp"分支，将存储库中的所有文件切换为开发服务器文件的版本，也可以类似地随时切换回"不稳定"。
当你想更新一个分支时，例如更新你的开发服务器，你可以将D_7"不稳定"merge转换为"devapp"。这将使"devapp"的所有文件看起来都像"不稳定"的文件，使其更新。
还有一点需要注意：优质回购、裸回购和克隆之间的差异几乎为零。软件上几乎没有区别；相反，说"Linus的内核是规范的Linux内核"是人类的惯例。有了这样的理解：
- prime repo只是一个所有人都同意拥有软件"规范"版本的存储库。也就是说，每当开发商做出改变时，他们都希望每个人都能看到，而不是说"撤回我的贬值版本"，他们可以说，"我已经发布了我对优质回购的改变。"这只是人们团结起来的一个简单惯例
- 克隆是其他repo的副本。我可以克隆主回购，进行更改，然后你可以克隆我的回购。如果您进行了更改，您可以将它们推送到主回购或我的回购上，只要合并有效并且您在计算机上有权限
- 裸repo根本没有"工作副本"——这台计算机上没有"webroot"目录。它是空的，只有
.git目录，这对于没有人需要更改文件的服务器来说很好
最后，.git目录不包含repo的文件，而是包含git配置和数据库。它是数据库形式的整个存储库历史记录，用于用特定版本的软件填充repo的其余部分。这就是我发表评论的原因：您可以本地在任何时候查看存储库的任何替代现实的任何版本，而无需网络通信，因为它都在.git目录中。唯一需要的网络通信是当您想使用push或pull将本地存储库同步到其他存储库时。