Gitのマスターブランチで作業しない理由
ですから、私はgitにかなり慣れていません。ここ数週間、マスターブランチを変更するのではなく、ブランチしてからマージする必要があると言っている人を何人か読んだことがあります。 。
私はブランチで作業するのに十分満足していますが、マスターブランチで作業しない理由について疑問に思っていましたか？
通常の理由は、マスターブランチがコードの「安定した」履歴を表す必要があるということだと思います。ブランチを使用して新しい機能を試し、実装します。ブランチが十分に成熟したら、それらをマージしてマスターに戻すことができます。
そうすれば、マスターのコードはほとんどの場合問題なくビルドされ、ほとんどの場合、リリースに直接使用できます。
例としてgit.git（公式のgitリポジトリ）を取り上げましょう。最も注目すべきいくつかのブランチがあります：
したがって、masterには、gitの次のリリースで終わる可能性が非常に高いコードが含まれています。 nextにはテスト済みのコードが含まれており、masterブランチにマージされる可能性があります。 pu（提案された更新、iirc）には、まったく新しい（そしておそらく）テストされていないコードが含まれています。
puは不安定であると見なされ、junioの好みに合わせてリセットおよびリベースされます。 nextは、リリース後またはリリースサイクル中にリセットされる可能性がありますが、これはあまり一般的ではありません。 masterは石に設定されており、プッシュされて一般に公開された後は変更されません。
ご覧のとおり、変更が価値があると見なされ、問題が発生しない場合、変更はpuからnextに、nextからmasterにマージされます。
ブランチmaintは、古いバージョンのgitにも適用されるバグ修正を行うために使用されます。 maintは通常、nextおよび/またはmasterにマージされます。
http://git.kernel.org/?p=git/git.git;a=summary でブランチを検査できます。
他の人々は、masterで直接変更を加えないことについて非常に良い事例を示しており、私は彼らに同意します。ただし、常にこのようなワークフローを提唱すると、gitを初めて使用する人は、それが不必要に複雑であると信じてしまうことがあるため、対位法を提供したいと思いました。
チームが1人または非常に小規模で、開発が非常に直線的である場合、つまり、一度に複数の作業を行うことはめったになく、各機能は通常、次の機能を開始する前に完了する場合、実際にはほとんどまたはまったくメリットがありません。 masterから直接作業します。必要に応じていつでも戻ってブランチを追加するのは非常に簡単です。機能ブランチのワークフローを知っておくことを強くお勧めしますが、あなたの場合、何も購入せずにステップを追加するだけだと感じた場合は、git警察に伝えないことを約束します。
GitやMercurialのようなDVCS（分散バージョン管理システム）で考慮する必要があることの1つは、「公開」ワークフロー（ 分岐ワークフローに直交 ）です。
支店しかない場合は、支店がどのような開発努力をしているのかを自問します。masterが安定したコードを表すことを意図している場合 knittl 詳細 彼の答え のように、はい、分岐/マージする必要がありますmasterへ。
ただし、クローン/プッシュ/プル（つまり、異なるリポジトリに公開され、それ自体が異なる目的を持つ可能性がある）が可能な場合、「master」はリポジトリごとに異なる役割を果たすことができます。
- 開発リポジトリには多くのブランチを含めることができ、通常は
masterが最も安定したコードを表します。 - デプロイメントリポジトリには、
masterと、緊急修正用の修正プログラムメンテナンスブランチのみを含めることができます。 - ローカルテストリポジトリは、そのテストリポジトリの
masterブランチのみを監視するフックによって静的分析コードを実行するために、プッシュからプッシュに書き直されたmasterブランチを1つだけ持つことができます。 - .。
両側でコミットを行う場合-つまり、ローカルリポジトリとアップストリームでコミットします。他のチームメンバーから-競合が発生する可能性があります。つまり、ファイルと特定の行が両方によって編集されたということです。この場合、手動のマージ処理が必要です。
masterブランチは、アップストリームにアクセスできない場合（モバイルの使用またはネットワーク障害）にアップストリームを表すローカルブランチを持つためのものです。アップストリームの変更を表すローカルブランチがあると、マージ解決などを行うのがはるかに簡単になります。
私の理解が正しいかどうかはわかりませんが、私はgitを初めて使用します。
いくつかの機能があると、作業が楽になると思います。プロジェクトがあり、機能Aで作業し、後で機能Bを実装するとします。
これで、フィーチャーA全体が間違いであると判断し、フィーチャーBのみを含み、Aを含まないバージョンのプロジェクトが必要になる可能性があります。すべてがマスターにある場合、このタスクは注意が必要です。
各機能が独自のブランチにある場合、このタスクは簡単です。古いマスターバージョン（AなしおよびBなし）を使用します。ブランチBをマージします。完了。