这个阶段直接commit并push到master上可以吗
理论上来说，不：master只能包含代码的稳定可用版本。
最好是在生产环境中运行的内容（您网站的实时版本）
正如查尔斯下面评论的那样，这取决于您在克隆存储库时默认要执行的操作
在第一个版本发布之前的初始开发阶段，git 的首选策略是什么？
你可以隔离它整合阶段在自己的分支上，这是一个或多个合并的结果特征分支 http://dymitruk.com/blog/2012/02/05/branch-per-feature/，以便一起测试所有功能。
第一个版本将看到：
- 合并到
master
- a tag
1.0
- a branch
1.0_hotfix done from said tag, in order to isolate hot fixes that:
- 你将合并到
master
- 您将合并到当前开发的其他功能分支
2.0如果您认为修补程序在新环境中有意义（由于某些 2.0 重构，某些错误实际上与 2.0 无关）
现在在实践中（这就是我同意的地方Charles https://stackoverflow.com/users/19563/charles-bailey's answer https://stackoverflow.com/a/16384556/6309), if all您正在开发的功能将首次发布，您could开发一切master，释放它，贴上标签1.0.
但一旦第一个版本完成，我仍然建议在他们自己的分支中隔离修补程序。
同样，取决于您想要的默认角色master有了分支，就可以直接在里面开发。
尽量避免从主分支合并到其他分支（“向后合并 https://stackoverflow.com/a/9098962/6309").
如果您有必须在过去的版本中移植的功能，请在将它们合并到之前在自己的分支中开发它们master以及其他发布分支。
作为遵循该模型的大型项目的示例（开发master，以及用于发布的分支），您可以看到的组织gitlabhq https://github.com/gitlabhq/gitlabhq.
我们的想法是只致力于master你的特征sure将进入下一个版本。
实验性功能（可能成功也可能失败）应该隔离在它们自己的分支中（或者在master, but in a cloned存储库，并通过拉取请求合并）。
