いつ新しいブランチを作成する必要がありますか？
私はバージョン管理システムの初めてのgitを使用しています。私は新しいプロジェクトを開始しているので、プロジェクトで使用されているテクノロジーを少し実験するために（hello worldの例...）、「遊び場」ブランチのようなものを作成したいと思います。新しいブランチ「playground」を作成するのが一般的ですか、それともマスターブランチにplaygroundという名前のフォルダーを作成する必要がありますか？
よろしく
本質的に実験的な開発作業を行う場合は、新しいブランチを作成する必要があります。したがって、シナリオでは、マスター内のフォルダーではなく、必ず新しいブランチを作成してください。サンドボックスワークをマスターのディレクトリとして作成した場合は、gitを使用して削除するまでそこに常駐します。デッドコードをマスターブランチに置くことは、他の開発者を混乱させる可能性があり、アプリケーションの存続期間中、そこにとどまる可能性があるため、決して理想的ではありません。
チームでバグが発生した場合、そのディレクトリ内にバグが存在するかどうかを判断するために実験的な作業を調査する時間を無駄にしたくないでしょう。新しいブランチを作成すると、変更をマスターブランチから分離できます。実験がうまくいけば、変更をマスターブランチにマージするオプションが常にあります。うまくいかない場合は、いつでもブランチを破棄するか、ローカルリポジトリ内に保持することができます。
ブランチには多くの用途があり、ワークフローによって少し異なります。一般的に使用される2つのワークフローは次のとおりです。
どちらも、いわゆるトピックブランチを使用して新しい機能を構築し、準備ができて受け入れられるとマージされます。
Githubのフローはかなり単純で、明らかにgithubが使用しているものです。 Gitflowはもう少し複雑で、修正プログラムを適用できるアプリの複数のバージョンをサポートする必要がある場合に適しています。
結局、どの種類のワークフローを使用するかは好みの問題ですが、ブランチの作成はgitで非常に安価であるため、作成するブランチの数は実際には重要ではありません（最終的には再度削除します）。
これらの場合は、新しいブランチの作成を検討し、それらに取り組む必要があります。-
サンドボックス環境で何かを作業/テストしたいとき。
コミットは本質的に短くすることをお勧めします。頻繁にコミットすると、他の開発領域に支障をきたす可能性があります。ブランチでの作業を完了してから、後でブランチをメインブランチにマージすることをお勧めします。 [Tip]メインブランチをブランチに頻繁にマージすることにより、ブランチをメインブランチと同期させることを忘れないでください。したがって、後の時点で、手作業でマージするものは多くありません。
バグを解決したい。他のブランチでそれを解決し、後でマージする方が良いでしょう。
コミットが失敗したりビルドが壊れたりしても、本番ビルドは影響を受けません。したがって、私は少なくとも2つのブランチdevブランチとprodブランチを使用することを好みます。すべてが完全にテストされたら、開発ブランチを本番ブランチにマージします。
あなたは実験することによって、しかし遊び場のレポで挑戦的に学ぶべきです。
リポジトリ内のプレイグラウンドディレクトリのメリットは少なくなります。
遊びをして、いくつかの間違いを犯して、いくつかのことを学びましょう。それを数回削除して、ワイルドになりましょう。
例えば.
$ mkdir playground
$ git init
$ touch hello-world
$ git add hello-world
$ git commit -m "my first commit"
$ git branch goodbye
$ git checkout goodbye
$ echo "goodbye" | cat >>hello-world
$ git status
$ git add hello-world
$ git commit -m "goodbye commit"
$ git merge master
また、GitHubから選択した言語でアクティブなプロジェクトのフォークを取得し、実際のコードとのマージ、リベースなどを試してみることをお勧めします。