我在我的工作流程中使用 git，并且我有一个远程测试服务器。最好的方法是什么。
目前我在我的工作站上进行更改并提交更改，然后推送到服务器。但这会很快导致许多小提交。我想避免在我的工作站上设置测试服务器。
并且 rebase 提交是不行的，因为我推送到其他人可以访问的裸存储库（然后有一个挂钩将其拉到作为测试服务器的工作目录）。
谢谢
【问题讨论】：
标签： testing workflow production rollout
我认为这里真正的问题是您想要“避免在 [您的] 工作站上设置测试服务器。”
QAM 的一个关键理念是，每个主机都可以尽可能地像生产系统，这样我们就可以最大限度地减少从开发到测试再到生产的工作量。
部署不是一个简单的过程，您的开发人员需要处理的越多，就越容易推出应用程序（以及不可避免的更新）。
所以你真的应该想，“我可以在我的开发机器上复制多近的生产环境？”
【讨论】：
小提交没有错。事实上，它们更可取，因为它们比大块补丁更容易审查。它们更好地展示了您的思维过程，并允许对工作进行小块审查。审阅者总是可以将很多小提交变成一个大提交，但反过来却做不到。这假设您的提交是逻辑块的形式。
但由于您在 之后 推送之前不会进行测试，我猜您的提交更像是“哎呀，我在上次提交时破坏了某些东西”的形式。这些都不好，会妨碍审查。理想情况下，它们应该是 --amended 到上一次提交。
编码、提交和测试阻碍了 TDD。您要做的是从已知的良好状态开始，编写代码，运行测试，查看失败，然后知道它是由您的非常小且易于调试的差异引起的。
这也意味着你将破坏性的更改推送到 master 中，这会搞砸团队中的其他人。
所以是的，您的开发机器上需要一个测试环境。只需按一下按钮即可运行并快速完成的东西（我们正在谈论分钟，顶部）。如果整个套件太慢或太麻烦，您可以只运行套件的一部分，也许您认为与您的更改最相关的部分，然后在您推送后让测试服务器运行整个套件。这是测试效率和彻底性之间的良好折衷。
如果由于某种原因您无法在您的开发机器上运行测试环境，您可以在自己的分支中工作并将其推送到测试。然后，如果它不起作用，您可以--amend 您的修复。完成功能后，您可以将更改合并到主文件中。这既消除了“哎呀，我破坏了它”的提交，又使您不会为其他人破坏 master，同时仍然可以进行小而易于审查的提交。
您应该使用测试服务器的目的是在尽可能接近生产环境的模拟中运行测试，开发人员机器通常是异构的，这很健康，并自动运行测试以防有人马虎。
【讨论】：
为什么不能在开发分支上进行小提交，然后将它们压缩成一个提交，然后合并回主分支，然后推送到服务器？我经常使用私有开发分支。
【讨论】：
我有一种情况，我正在开发一种用于处理敏感数据的工具。这意味着我的开发环境只有静态测试，我需要部署到一个无法访问常规生产 Git 的隔离服务器。
我最终做的是在生产服务器上设置处理脚本的测试实例，并在开发期间经常部署到该实例，但我并不完全满意。
以前，我们使用的是 Subversion，我在此基础上设置了 Darcs，效果很好。编辑，提交到 Darcs，推送到测试，泡沫冲洗重复，提交到 SVN，推送到生产。
与 Darcs 相比，Git 更容易混淆，但通过观察我可以在测试实例中拥有一个实时 Git 存储库，并且我只需要简单地将其切换到不同的分支，我已经合理地做到了这一点为了能够推动。
#!/bin/sh
set -e
branch=${1-dev}
# Temporarily switch to a different branch so that pushing is safe
ssh server 'cd project &&
{ git branch -d trash 2>/dev/null || true
git checkout -b trash; }'
git push server:project "$branch"
# Switch to the newly pushed
ssh server "cd project && git checkout $branch"
使用 Darcs，我能够在测试服务器上进行编辑并将其拉回，但使用 Git，我觉得我需要避免这样做。
【讨论】：