回答:
すぐに。
キーは、マスターのポリシーが何であるかという問題です。gitでは、通常、Masterのブランチポリシーはビルド可能な安定版リリースです。マスターは、ブランチが作成され、リリースブランチにマージされる前にマージされる「メインライン」である場合があります。これらは2つの異なるロール/ポリシーアプローチです。
多くの場合、プロジェクトの途中でブランチの役割またはポリシーを変更することは、人々のエラーの原因になります。ソロ開発者はこれらの変更を寄稿者に伝えるのが簡単ですが、多数のプログラマーに「マスターは1.0になりました。全員にプッシュするのではなく、機能を分岐してください」と認識させようとしています。
上記の政策アプローチについて触れました。マスターのポリシーは、ビルド可能な安定版リリースであるということです。これに小さなインクリメンタルな変更をチェックインすることは、常に安定したビルド可能なものがないことを意味します。小さな変更をチェックインしないと、最良のポリシーになる傾向がある（そして簡単な分岐によって奨励される）「多くの小さな（しかし完全な）チェックイン」に反します。
役割ベースの観点から、マスターがメインライン、リリース、メンテナンス、および開発の役割であることに始まり、その後、開発と保守の役割がブランチに移行する道を指し示します。これもまた、マスターで許可されるものの変更を意味し、物事がどこに属しているかに関して貢献者を混乱させる可能性があります。また、ブランチの履歴を（わずかに）混乱させる可能性があり、マージがより大きく、より理解しにくいことを意味する大規模なコミットを促進します。
ブランチの役割とポリシーを最初からシンプルで一貫性のあるものにします。
この「ポリシー変更の分岐」は、分岐パターンで確認できます。各ブランチに役割があるという考え方は、Advanced SCM Branching Strategiesで読むことができます。これらは両方とも非常に優れた読み取りです。
通常、ブランチでの作業を開始したい状況は主に2つあります。
あなたまたはあなたのチームが次のリリース（これが初めてのリリースである可能性があります）に追加されない可能性が最も少ない新機能を開始する必要がある場合、別の機能ブランチで開発を開始します
重大なバグの修正を最新リリースに提供する必要があり、それらの修正のみを含む新しいバグ修正リリースを作成したいが、新しく開発された（およびおそらく不安定な）機能は必要ない場合
この種の決定については、プログラムの最初のコンパイル可能/実行可能なバージョンがある時点から、常に「新機能」または「バグ修正」の観点から考えるのが役立つと思います。
Michael Feathersは有名な本の中で変更する4つの理由をリストしていますが、私は「リソースの最適化」を「新機能ブランチ」（非機能機能用）に、「デザインの改善」を「新機能ブランチ」の下に配置します、これは特定の機能の実装を容易にすることを目的としていない場合、IMHOは設計を改善すべきではありません。
あなたが続く場合はgit-流れを -率直に言って、そして、私はあなたがしている非常識だと思いますが、Gitリポジトリを使用している場合していないモデルを分岐することを使用-あなたがすべき決してにコミットしていないmasterあなたが実際に公共のリリースの準備が整うまで。
最初のコミットmasterは空のリポジトリである必要があります。次のコミットmasterは、developブランチまたは一時リリースブランチからのマージコミットであり、安定し、テストされ、展開（アプリケーションの場合）またはパブリック配布（ライブラリの場合）の準備ができている必要があります。
Gitには他にも分岐モデルがありますが、そのほとんどは古い集中型SCMモデルから派生したものであり、DVCS環境で深刻な問題を引き起こす可能性があります。実際にgit-flow拡張機能を使用する必要はありません。また、必ずしもすべてのリリース/修正プログラム/機能ブランチが必要というわけではありませんが、裸の骨はdevelopand masterであり、不安定なコードが入りdevelopます。
master。mastergitにとって特別なものではないことを思い出してください。そこにある必要はありません。リリースを作成するまで、開発ブランチを作成できます。
ThoughtworksのNeal Fordは、「地獄の合併」の問題を回避するために、分岐を介した機能トグルの使用を提唱しています。2人のプログラマがメインブランチから毎日忠実にマージし、そのうちの1人が数週間にわたってかなりの変更を加えてからコミットする場合を考えます。他のプログラマーは非常にうまくマージ地獄に陥る可能性があります。この問題を回避するために、Fordは、ブランチを1つだけにして毎日コミットすることにより、「痛みを軽減する」こと（よく知られているアジャイル属性）を推奨しています。追加の機能は、完全にテストされるまで機能を無効にする機能トグルを介して追加されます。
この方法論は、コミットの問題が即座に検出されるため、継続的配信を実装する環境で最適に機能するようです。
この質問に対する最後の回答から2年が経ちましたが、今は物語が変わると思います。私にとっての答えは、「ソースコード管理を使用してバージョンを追跡するたびに」です。
詳しく述べると、最近ではソースコード管理を使用したプロジェクトバージョンの追跡が常に機能するとは限りません。（たとえば、npmを使用して依存関係を管理し、セマンティックバージョンを '^'で指定する）その場合、ビルドが発生するたびにプロジェクトのアーティファクトが変更され、ソースコードの変更に対応する必要はありません。この種の新しい課題に対処するために、一部のチームは、プロジェクトバージョンを追跡するために、アーティファクト制御システム（例：JFrog Artifactory）に保存された「アーティファクト」をすでに構築していることを選択します。
明らかに、アーティファクトのバージョン管理が既に整っている場合、GITブランチから「製品コード」をプルしてプロダクションにビルド/デプロイするのではなく、デプロイメントのために直接実行可能なバージョンのアーティファクト制御システムに相談します。そのような場合、「リリースブランチ」の概念は突然その意味を失います。また、チームがgitブランチをリリースバージョンに関連付けないことを決定するたびに、マスターに直接コミット/プッシュすることは再び適切な選択肢になります：リポジトリが複製されるたびにデフォルトのブランチとして提供されるため、広く受け入れられ、十分に伝達されたセマンティクスが自動的に与えられます変更。それでも、受け入れられた答えが示唆しているように、おそらくmasterを含むブランチにロールを割り当て、それらの特定のロールに対してのみそれらのブランチを使用する必要があります。
最後に、私はさらに一歩進んで、少数のコアコミッターのみを含むプロジェクトの開発ブランチとしてmasterを使用することを提案します。これは私のチームの場合であり、おそらくほとんどのマイクロサービスショップでも同じです。マスターでコミットすると、変更プロセスの通信が削除され、複数のスプリントにまたがる機能で作業する際の「地獄のマージ」が回避される可能性があります。さらに、masterブランチのコードは「動作」する必要さえありません。自動化されたビルド/テストプロセスが何が間違っているかを教えてくれるので、とにかくgit履歴を確認してビルド/テストを中断した作者に連絡するのは簡単です:-)