我对git还很陌生，不太确定做我需要做的事情的最佳方式是什么。
所以我的设置是这样的：我有我的本地主机，我在那里工作，然后我有一个测试环境，客户端可以在那里测试新功能，然后我就有了生产环境。
生产环境最近才上线，在那之前，我一工作（只是由我测试）就把所有东西都推到上线和测试服务器上，这还可以，因为系统还没有100%上线。现在，客户希望我将所有内容推送到测试服务器，并允许他们对其进行测试，让我知道哪些部分已经准备好投入使用，哪些部分还需要工作。在不意外将尚未准备好但已推送到测试服务器的活动服务器上的情况下，处理此问题的最佳方法是什么。
我以为我可以在工作时创建分支，当它工作时，将它合并到测试分支中，推送到测试服务器，并删除功能分支，但后来我似乎不得不一次将其全部推送到生产分支，而不是选择我想要的功能，只推送那些活的功能。
以下是我能想到的选项：
选项1-为每个bug修复和功能请求创建一个新分支，并将它们合并到测试分支进行测试，然后在每个测试完成后将它们单独与生产分支合并。
选项2-告诉客户，我必须一次推送大量更新，而不仅仅是他们挑选的一两个。（显然不是最好的选择）
选项1的问题是，我认为我必须在master或production分支之外创建每个分支，并且一些修复或功能可能依赖于dev分支中已经修复但尚未投入生产的其他内容。
我希望我缺少git的一些功能，这些功能在这种情况下会有所帮助。
如有任何建议，我们将不胜感激。
提前谢谢。
git flow是很多人所推崇的东西。我建议大家看看。
我个人的Git工作流程是这样的。
所有新作品都进入自己的分支，以master为基础
为此，我使用git checkout -b my-new-branch。如果master在我开发的过程中发生了变化，那么我可以切换回那里——git stash（如果我有任何变化），然后git checkout master——然后git pull --rebase master，以获得最新的变化。一旦我得到了master的最新更改，然后我切换回另一个分支git checkout -，然后切换到git rebase master。
基于现有非主分支的工作基于该分支
与上面类似，但git checkout -b在非主分支上运行。
这些"规则"几乎让我度过了每一天。至于您的testing分支，我会将其称为类似staging的分支（如在"暂存区"中），然后根据需要使用git merge <branch name>将（而不是重新基础）分支合并到其中。那么staging就会有正确的东西。
当您想将其添加到生产中时，您也可以在那里合并分支：git merge <branch name>。我不建议在staging上重新设置基础，因为这会使事情复杂化，而且不应该对登台进行任何额外的更改。任何工作都在一个分支上进行，然后将其合并到staging中，验证为工作，然后合并到production中。