Git-マスターで直接作業することから生じる問題は何ですか？

gitブランチモデルに関する多くのアドバイスを見てきましたが、最も一般的な意見は、masterブランチで直接変更を加えることは悪い考えだと思われます。

同僚の1人がmasterブランチ上で直接変更を行うことを非常に喜んでおり、いくつかの会話にもかかわらず、彼らはこれを変更する可能性は低いようです。

現時点では、マスターに直接取り組むのは悪い習慣である同僚を納得させることはできませんが、私は彼の働き方と矛盾することを理解し、いつ再訪する必要があるかを知りたいですこの問題。

コミットが直接マスターにプッシュされる場合、いくつかの問題があります

• 進行中の作業状態をリモートにプッシュすると、マスターが破損している可能性があります
• 別の開発者がマスターから新機能の作業を開始する場合、潜在的に壊れた状態から開始します。これにより開発が遅くなります
• さまざまな機能/バグ修正が分離されていないため、進行中のすべての開発タスクの複雑さが1つのブランチに統合されます。これにより、すべての開発者間で必要な通信量が増加します
• コードレビューのための非常に良いメカニズムであるプルリクエストを行うことはできません
• 他の開発者がその間にすでにマスターブランチをプルしている可能性があるため、一般的にコミット/スカッシュを変更することはできません

新機能には、運用環境にプッシュする前にテスト環境に展開できる独自の開発ブランチが必要であることを彼に説明してください。

それ以外の場合は、機能が半分完成した状態になります。半分完成した機能を実稼働環境にデプロイすることはできません。したがって、masterブランチで直接作業している場合、他の人は、バグ修正を含む他の誰かの変更が実稼働環境に移行する前に、機能の終了を待つ必要があります。

機能に独立したブランチを使用するということは、各新機能を他の機能とは独立してテストおよび展開できることを意味します。

マスターは解放される可能性があります。期間。マスターに半分の作業が終了してはいけません（機能フラグで無効にされていない限り）

それで、私はいくつかのチームが彼らの流れを複雑にするのを見ました。

マスターに統合するときにPRを使用しないのは間違いです。なぜなら、開発者は統合がいつ行われるかを選択する権限を持たないからです。

単一の開発ブランチでは、ほとんど価値がありません。通常、それは物事を複雑にします。多くの機能ブランチは多くの価値をもたらします。

各環境（dev、test、prod）にブランチを作成するのは間違いです。これはgitの範囲外であり、リリースパイプラインで処理する必要があります。まったく同じビルドをすべての環境に展開する必要がありますが、各環境にブランチがある場合は不可能です。

機能が非常に大きい場合、1日または2日で実行することはできません。機能ブランチに対するすべての作業は別々のブランチで行い、PRと統合する必要があります。

• マスターは、実際の最終バージョンである本番ブランチを反映する必要があります。
• 直接マスターで作業するということは、バグを作成する場合、コミットを元に戻す/削除/リセットする以外に「戻る」オプションがないことを意味します。これは、きれいな作業方法ではなく、新しいコードの一部を失う可能性があります大丈夫だった。
• もちろん、開発の最初の段階では、おそらくmasterで直接作業を開始できますが、提供するものがある場合は、開発ブランチ、テストブランチ、またはテストブランチを使用して、公開済みの完全な作業バージョンに手を触れないようにする必要があります。

まず、gitでは、すべてpullが文字通り分岐操作であり、すべてpushがマージであることを指摘しておきます。master開発者のマシン上では完全に分離支店でmaster技術的な観点から等しい立って、あなたが共有する中央レポに。私は、ローカルバージョンの名前をupstream、目的に合ったものに変更したりすることがあります。

これは、多くの組織が同僚よりも効果的にブランチを使用していると考えているためです。実際、彼らは途中でブランチに追加の名前を作成するだけで、それはいずれにしても履歴に保存されません。同僚が1つのアトミックコミットで機能をコミットする場合、機能ブランチのマージコミットと同じくらい簡単にバックアウトできます。機能ブランチの大部分は非常に短命であり、とにかく頻繁にマージされる必要があります。

とはいえ、彼の働き方の主な欠点は2つあります。まず、未完成の機能でのコラボレーションが非常に困難になります。ただし、コラボレーションが必要な場合にのみブランチを作成することは難しくありません。

第二に、マージ前のレビューが非常に困難になります。この点で、実際に彼を説得する必要はありません。github、gerrit、gitlabなどのツールを採用でき、すべてのマージでプルリクエストコードのレビューと自動テストに合格する必要があります。このようなことをしていない場合、率直に言ってgitを最大限に使用していないため、同僚がその可能性を認識していないのも不思議ではありません。

他の回答では、マスターではなく直接作業する場合のさまざまな利点（分離された機能、マスターで常に出荷可能なコードなど）について既に言及しています。

私にとって、あなたは別の問題を抱えているようです。明らかに、すべての開発者が同意または使用している開発プロセスはありません（または、問題の開発者はプロセスを完全に無視しています）。

マスターにマージされる機能ブランチがありますか、それとも異なるリリースブランチがありますか、またはまったく異なるプロセスを使用しますか？

「masterブランチを使用しない」では不十分です。

同僚の1人がmasterブランチ上で直接変更を行うことを非常に喜んでおり、いくつかの会話にもかかわらず、彼らはこれを変更する可能性は低いようです。

これは私にもっと問題があると信じさせます。マスターに取り組むか否かは、主に、製品をリリースする方法、対象、時期に関する大きな哲学の一部です。

「マスターで作業するべきではありません」と並行して、機能のテストはありますか、お互いの動作をテストしますか、お互いのコードを確認しますか。受け入れおよび統合テスト。

上記のどれも持っておらず、「gitを実行」するためだけにやっているのであれば、masterで作業することもできます。

ブランチに直接取り組むことに関して「悪い練習」はありません。ただし、プロセスを最もよくサポートするものを決定する必要があります。

質問1：マスターは、ソフトウェアの現在のリリース状態を表す必要がありますか？次に、グローバル開発ブランチを導入し、リリース開発の最後に開発をマージする必要があります。

質問2：コードレビュープロセスが必要ですか？次に、プルリクエストを介してマスターにマージされる（または、ある場合は開発する）「機能ブランチ」が必要です。

質問3：まだ運用環境（またはテスト）に公開すべきではない中間コードの状態を他の開発者と共有する必要はありますか？これは、複数の開発者が機能を開発する場合です。次に、「機能ブランチ」を導入する必要があります。