我希望我的代码的几个不同版本，在其开发生命周期的不同阶段，能够受到版本控制，并始终同时在web上运行。版本通常命名为development、staging和live，其结构如下树所示。
Sitename
|--Development
|--Live
`--Staging
- 创建三个独立的存储库更好还是创建一个有三个分支永久签出的存储库
- 每个工作流各自的优点和缺点是什么
- 作为Git的新手，我如何实现首选的工作流程
附录
我更喜欢创建一个存储库，但这意味着在Sitename下创建存储库，并在其中有三个工作目录，但我的理解是Git不支持嵌套的工作目录。我知道一个名为git-new-workdir的有贡献的解决方案，但我读到新用户使用此工作流可能会遭受更多的后果而不是好处，所以我对替代方案感兴趣。
保留一个存储库。为分支机构制定一个大会。通常是这样的：
master：表示服务器上运行的代码以及用户体验的内容
staging：（可选）表示部署到您的staging服务器的代码以及您选择的测试人员使用的代码。
候选版本或RC：所有单独测试过的功能，以及与其他功能一起测试过并通过的功能。这可以在任何时候合并到master和/或staging。
集成或dev：集成过去和现在（完整和不完整）的所有功能，以获得关于现在失败的反馈。
功能或任务：（通常命名为票证编号）包含一个功能-最好从一个公共点开始，作为迭代中的其他功能。
我建议使用以下工作流进行管理：http://dymitruk.com/blog/2012/02/05/branch-per-feature/
没有什么是板上钉钉的，只要确保你有条理，始终如一，做对你的团队有意义的事情。
不确定是否可以通过git post签入实现这一点挂钩。我会考虑一个真正的构建服务器解决方案（例如TeamCity、FinalBuilder）。构建服务器监视三个不同分支上的存储库，然后将它们部署到您想要的位置。
这是一个老问题，但仍然有很多观点，所以我认为它应该得到一个正确的答案。当我问这个问题时，我对SVN很熟悉，但对Git来说是个新手，但三年后的今天，我觉得有资格回答这个问题
这个问题最相关的部分是：
是创建三个独立的存储库更好，还是创建一个具有三个永久检出分支的存储库？
如果必须在这两个选项之间做出选择，那将是后者，但正确答案是两者都不是为不同的环境创建不同的存储库与为不同环境创建不同分支一样不正确。
使用Git的正确方法是为一个项目提供一个存储库。存储库可以根据需要进行多次克隆。正如不同的用户可以签出不同版本的代码一样，不同的环境也可以从他们的存储库副本中签出不同的代码版本。不同的环境可能只是代码的不同用户。