我对git相当新，我不太清楚做我需要做的最好的方法是什么。
所以我的设置是这样的：我有我的localhost，我在那里工作，然后我有一个测试环境，客户端可以测试新的功能，然后我有生产环境。
生产环境刚刚开始运行，直到那时我一直在将所有内容推送到实时和测试服务器一直工作（只是由我测试），这是好的，因为系统尚未100％生效。现在，客户希望我将所有内容推送到测试服务器并允许他们对其进行测试，并让我知道哪些部件已准备就绪，哪些部件仍需要工作。什么是处理此问题的最佳方法，而不会意外地将事物推送到尚未准备好但已经被推送到测试服务器的实时服务器。
我以为我可以在处理事情时创建分支，当我将其合并到测试分支并将其推送到测试服务器，并删除功能分支时，我似乎必须推送这一切都是生产分支，而不是选择我想要的功能，只推动那些功能。
以下是我能想到的选项：
选项1 - 为每个错误修复和功能请求创建一个新分支，并将它们合并到测试分支进行测试，然后在每个测试分支之后将它们与生产分支合并。
选项2 - 告诉客户我必须立即推送一大批更新，而不仅仅是他们挑选的一两个。 （显然不是最好的选择）
我对选项1的问题是，我假设我必须从主分支或生产分支创建每个分支，并且某些修复或功能可能依赖于已在dev分支中修复但已具有的其他内容尚未推向生产。
我希望我错过了git的一些功能，这些功能会在这种情况下有所帮助。
任何建议都将不胜感激。
提前致谢。
答案 0 :(得分：1)
git-flow是许多人发誓的事情。我建议看一下。
我自己的个人Git工作流程是这样的。
为此，我使用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在非主分支上运行。
那些＆＃34;规则＆＃34;每天都让我度过难关。至于你的testing分支，我会称之为staging（如＆＃34;暂存区＆＃34;）然后 merge （不是rebase）分支因为我需要使用git merge <branch name>。然后staging会有正确的事情。
如果要将其添加到生产中，您也可以合并分支：git merge <branch name>。我不建议在staging上进行重新定义，因为这会使事情复杂化，并且真的不应该对分段应用任何额外的更改。任何工作都在分支上进行，然后合并到staging，验证为有效，然后合并到production。