我一直在研究Git，我得到了基本的概念，除了它如何适应小团队的工作流程。
据我了解，我想要：
为我和我的团队共享一份半公开回购协议（将更改纳入本地副本）并测试功能。
我们推出经过测试并准备上线的任何回购。
实时回购，其中工作目录是实际网站的根文件夹
我是理解这一点还是比它需要的更复杂？只是试着把我的思绪包围起来，很少有教程详细介绍这个主题。
答案 0 :(得分：0)
我的开发团队只有一个远程仓库，其中所有更改都被推送。
开发中的功能是分支的，以避免破坏主副本，因此可能同时存在多个活动分支。每个开发人员都有一个“本地”仓库，它实际上在开发服务器上运行（我们倾向于通过SSH使用VIM进行开发）。每个“本地”存储库都设置为一个唯一的虚拟主机，该主机使用用户名进行标记。因此，在开发服务器上运行的站点可能有三个或四个不同版本。这允许开发人员立即测试代码更改。
准备发布时，将合并所有已完成的分支，并将生成的代码通过git提取到与生产环境紧密匹配的预部署服务器。批准后，特定提交标记有版本号，并使用git或rsynched提取到生产服务器上，然后再进行一些测试以确保部署顺利进行。
答案 1 :(得分：0)
您可以应用许多git工作流程，但如果您需要一个起点，我建议使用nvie blog post来解释通过分支管理应用程序更改的良好集中方式。
您可以在http://progit.org/book/ch3-4.html上了解更多相关信息。
此外，似乎有人已经问过这个问题：Git branch strategy for small dev team
答案 2 :(得分：0)
而不是使用多个存储库进行开发/发布/ ...我会在一个存储库中使用分支。
可以在此博客文章中找到有关该模型的更多想法（以及如何在团队中使用它）： http://nvie.com/posts/a-successful-git-branching-model/
（不要害怕，顶部的图表看起来很复杂，但如果你刚看完文章就会变得非常清楚:)）
在一个不相关的说明中：Git非常强大，对很多东西都有好处，但使用起来也很复杂（正是你对内核黑客编写的版本控制系统的期望; D）。
对于分散的VCS，Bazaar可能是一个不错的选择。它与git共享基本思想。但是我从很多不同的人那里反复听到，对于那些没有计算机科学背景并且可能是第一次使用版本控制的团队来说，它往往更容易处理。
（以防万一符合您的标准。我不了解您的团队，而且人们的背景和经验范围在网络开发方面相当广泛。不想创建VCS这里也有火焰。）