感谢您对问题的更新，现在更清楚了。
我相信您遇到的问题是基于对 Git 工作流程的误解；Git 不会将目录等同于分支，它会将文件系统的视图等同于分支。这是强大的 - 但很容易在脚下射击自己。让我解释。
Git 本身更像是一个数据库支持的、不同版本的、历史跟踪文件系统。它在您的文件系统“之上”，而不是它的“一部分”。它不使用您的文件系统来表示分支，而是当您签出不同的分支时，文件系统中的所有文件都将更改为该分支中的文件。您要求 Git 使您的文件系统代表该分支的替代现实。
如果您在 branch 上master，并且它有一个已root/foo.txt提交的文件，并且您检查了没有已提交的 branch experiment，那么当您查找该文件时，您会发现该文件已消失。它是, not的一部分，因此它不存在于您的文件系统中。这就是为什么 Git 在允许您切换分支之前对提交当前分支非常挑剔的原因 - 如果您在文件系统上有 Git 不知道的未暂存更改，它拒绝通过用不同的现实覆盖它们来将它们吹走。您必须先进行干预才能使事情正确。root/foo.txtmasterexperiment
所以，要回答这个问题，不要为“myliveapp”和“devapp”创建子目录——创建不同的分支。只需将您的一个代码库放在“webroot”下即可。然后，破解“不稳定”分支，像往常一样提交更改。然后，您可以通过切换到“devapp”分支将存储库中的所有文件切换为开发服务器文件的版本，并且您可以随时切换回“不稳定”。
当你想更新一个分支时，例如更新你的开发服务器，你可以merge“不稳定”进入“devapp”。这将使“devapp”的所有文件看起来像“unstable”的文件，使其保持最新。
另一件需要注意的事情：prime repo、bare repo 和 clones 之间的区别几乎为零。软件几乎没有区别；相反，说“Linus 的内核是规范的 Linux 内核”是人类的惯例。有了这样的理解：
- 主要存储库只是每个人都同意拥有软件“规范”版本的存储库。也就是说，每当开发人员进行了更改，他们希望每个人都看到，而不是说“拉我的 devapp 版本”，他们可以说，“我已经将我的更改发布到我们的主要 repo 中。” 这只是一个让人们团结起来的简单惯例。
- 克隆是其他一些 repo 的副本。我可以克隆主要存储库，进行更改，然后您可以克隆我的存储库。如果您进行更改，您可以将它们推送到主要仓库或我的仓库，只要合并有效并且您对计算机具有权限。
- 一个裸仓库根本没有“工作副本”——那台计算机上没有“webroot”目录。它只有目录是空的
.git- 这对于没有人需要更改文件的服务器来说很好。
最后，该.git目录不包含您的 repo 文件，它包含 git 配置和数据库。它是数据库形式的整个存储库历史记录，用于使用特定版本的软件填充存储库的其余部分。这就是我发表评论的原因：您可以随时在本地检查存储库的任何替代现实的任何版本，而无需网络通信 - 因为它都在 .git 目录中。唯一需要的网络通信是当您想要将本地存储库同步到其他存储库时，使用push或pull。