我们使用Git作为源代码控制，我想知道最好的方法是让我的客户查看每个功能分支（作为网站本身）以审查和批准新功能。 （我们可以在任何时候为客户开发几个不同的功能 - 所有功能都在不同时间上线）
目前，我们必须为每个分支创建单独的测试站点。 E.g：
Master branch (live): www.lovelywebsite.com
dev branch: lovelywebsite-dev.mytestsite.com
new-homepage branch: lovelywebsite-new-homepage.mytestsite.com
new-feature1 branch: lovelywebsite-new-feature1.mytestsite.com
每次创建新分支时，此方法需要花费大量时间来设置新的测试站点（包括db等）。它还会占用我们的服务器资源。 （某些网站的大小可以是多GB）
我们需要能够允许客户端查看这些功能并批准它们，然后才能合并到主服务器并推送。
其他人如何实现这一目标？
答案 0 :(得分：2)
这真的不是git问题，只是因为您恰好使用git作为源控件。无论您如何跟踪源代码，问题都是相同的：您需要部署各种功能进行测试。没有git特定的解决方案......
有几种方法可以看问题，但没有一个神奇的子弹。一般来说，我建议您查看自动构建/部署工具。 （不能专门推荐一个;关于你的项目/技术堆栈的变量太多。但是Jenkins，TeamCity，Octopus Deploy等工具......）其他一些想法：
所有功能的一个测试环境
所以我不是说这在理论上是理想的，但是当你问人们如何在实践中处理这个问题时：
许多组织只有一个测试环境，并且随着功能准备好进行测试，它们将合并到一个测试就绪分支中，以便部署到此环境中。当然，也许你在测试环境中有一个主页重新设计和一个新的联系页面，一个在另一个之前上线......但通常组织不关心。两个部署后，都可以进行审核。
“但如果他们审查整个网站，他们会看到他们没有预料到的变化。”是的，这些变化越紧密，可能会越麻烦。 （也就是说，如果在此页面上有一个更改而在该页面上有另一个更改是一回事;如果一个更改修改此页面的内容而另一个更改其样式，则是另一个;等等）但它归结为与业务/审阅者的通信问题
这不仅经常被接受，而且确实具有一些优势。因为最终您确实需要将这些功能部署在一起。如果你让用户单独测试它们中的每一个，并且当它们全部合并在一起时代码以一种不可预见的方式进行交互......那么，这是你应该测试的另一件事。 （而且，这也是一个更大的问题，特征越重叠。）
这是一个选择。这很简单。许多组织认为可以接受。
但也许你没有，那还有什么呢？
一次一个测试环境
也许你可以部署最紧急的功能，然后一旦它注销就部署下一个功能。这是否实用在很大程度上取决于您的UAT与客户端是否通常会进行大量的来回反复。 （如果确实如此，您可以考虑采用实践来减轻这种情况 - 整个过程中更多的客户参与。但涉及的流程变更是一个更广泛的主题，主要属于“敏捷开发”标题。）
如果可行，这会做两件事。显然，它减少了服务器资源问题，因为不需要同时部署多个多GB站点。此外，由于部署目标是不变的，您只需更改要部署的分支，因此可以更轻松地设置自动构建/部署工具，从而减少时间/工作量开销。
但是，也许它不适合你的需要;如果你绝对肯定地必须一次性提供所有版本呢？
轻量级部署
根据您的站点技术，您可能会使每个站点的部署过程变得不那么麻烦。这对您的服务器资源可能做的很少，但有一些事情：
听起来您正在为每个站点设置单独的主机名。如果不是
，该怎么办？lovelywebsite-new-homepage.mytestsite.com
你用过
lovelywebsite.mytestsite.com/newhomepage
所以一切都部署到单个服务器（或服务器场），没有每个分支的DNS设置，可能是每个变体的轻量级设置。同样，细节很大程度上取决于您网站的技术，但这可能是您可以考虑的事情。
OTOH，也许您正在部署到物理上不同的服务器，以避免一台服务器过度负担。 （也许你有指标支持这样做的必要性。）那么我们还有什么呢？重组项目
我们已经没有“简单”的解决方案了。听起来你有一个相当大的网站。也许在开发/测试时，它们可以分成许多较小的，可独立部署的子站点，能够配置所有未测试的部分，以推迟反映生产的“默认站点”吗？
这样的解决方案的明显问题是，除了复杂性和开发项目特定技术来划分网站的需要之外，测试站点不像最终运行的生产站点那样理想应该是 - 这些差异可能会造成幻影错误或掩盖真实错误。