36

バージョニングシステムで初めてgitを使用しています。私は新しいプロジェクトを開始しているので、プロジェクトで使用されているテクノロジーを少し実験するために（hello worldの例...）、「遊び場」ブランチのようなものを作成したいと思います。新しいブランチ「playground」を作成するのが一般的ですか、それともマスターブランチにplaygroundという名前のフォルダーを作成する必要がありますか？

よろしく

4

5 に答える 5

43

本質的に実験的な開発作業を行う場合は、新しいブランチを作成する必要があります。したがって、シナリオでは、マスター内のフォルダーではなく、必ず新しいブランチを作成してください。サンドボックスワークをマスターのディレクトリとして作成した場合は、gitを使用して削除するまでそこに常駐します。デッドコードをマスターブランチに置くことは、他の開発者を混乱させる可能性があり、アプリケーションの存続期間中、そこにとどまる可能性があるため、決して理想的ではありません。

チームでバグが発生した場合、バグがそのディレクトリ内に存在するかどうかを判断するために実験的な作業を調査する時間を無駄にしたくないでしょう。新しいブランチを作成すると、変更をマスターブランチから分離できます。実験がうまくいけば、変更をマスターブランチにマージするオプションが常にあります。うまくいかない場合は、いつでもブランチを破棄するか、ローカルリポジトリ内に保持することができます。

于 2013-03-26T09:29:04.467 に答える
10

ブランチには多くの用途があり、ワークフローに少し依存します。一般的に使用される2つのワークフローは次のとおりです。

どちらも、いわゆるトピックブランチを使用して新しい機能を構築し、準備ができて受け入れられるとマージされます。

Githubのフローはかなり単純で、明らかにgithubが使用しているものです。Gitflowはもう少し複雑で、修正プログラムを適用できる複数のバージョンのアプリをサポートする必要がある場合に適しています。

結局、どの種類のワークフローを使用するかは好みの問題ですが、ブランチの作成はgitで非常に安価であるため、作成するブランチの数は実際には重要ではありません（最終的には再度削除します）。

于 2013-03-26T09:32:54.720 に答える
9

これらの場合は、新しいブランチの作成を検討し、それらに取り組む必要があります。-

  • サンドボックス環境で何かを作業/テストしたい場合。

  • コミットは本質的に短くすることをお勧めします。頻繁にコミットすると、他の開発領域に支障をきたす可能性があります。そのため、ブランチでの作業を完了してから、後でブランチをメインブランチにマージすることをお勧めします。[ヒント]メインブランチを頻繁にブランチにマージすることにより、ブランチをメインブランチと同期させることを忘れないでください。したがって、後の時点で、手作業でマージするものはあまりありません。

  • バグを解決したい。他のブランチで解決し、後でマージする方がよいでしょう。

  • コミットが失敗したり、ビルドが壊れたりしても、本番ビルドは影響を受けません。したがって、私は少なくとも2つのブランチdevブランチとprodブランチを使用することを好みます。すべてが完全にテストされたら、開発ブランチを本番ブランチにマージします。

于 2013-03-26T09:53:01.793 に答える
3

あなたは実験することによって、しかし遊び場のレポで挑戦的に学ぶべきです。
リポジトリ内のプレイグラウンドディレクトリのメリットは少なくなります。
遊んで、いくつかの間違いを犯して、いくつかのことを学びましょう-それを数回削除して、ワイルドになりましょう。

例えば

$ 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から選択した言語でアクティブなプロジェクトのフォークを取得し、実際のコードとのマージ、リベースなどを試してみることをお勧めします。

于 2013-03-26T09:38:29.717 に答える
2

一般的な方法は、マスターブランチをライブブランチとして使用することです。次に、マスターから新しいブランチを作成し、それらに取り組みます（機能ブランチ）。作業が終了したら、変更をマスターにマージします。

プレビューのみが必要な場合は、devブランチのような新しいリモートブランチを構築し、変更をこのブランチにマージできます。いくつかの方法がありますが、グーグルにはたくさんの情報があります。

Git分岐モデルの分岐とマージ

于 2013-03-26T09:34:27.677 に答える