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