Git-マスターで直接作業するとどのような問題が発生しますか？
Gitブランチモデルに関する多くのアドバイスを見てきましたが、最も一般的な意見は、masterブランチに直接変更を加えることは悪い考えだと思われます。
私たちの同僚の1人は、masterブランチで直接変更を行うことに非常に満足しており、いくつかの会話にもかかわらず、これを変更する可能性は低いようです。
現時点では、マスターに直接作業するのが悪い習慣である同僚を納得させることはできませんが、彼の作業方法と競合することを理解し、いつ再訪する必要があるかを知りたいこの問題。
コミットがマスターに直接プッシュされるときにいくつかの問題があります
- 作業中の状態をリモートにプッシュすると、マスターが壊れる可能性があります
- 別の開発者がマスターから新機能の作業を開始した場合、彼女は潜在的に壊れた状態から始めます。これは開発を遅くします
- さまざまな機能/バグ修正が分離されていないため、進行中のすべての開発タスクの複雑さが1つのブランチにまとめられています。これにより、すべての開発者間で必要なコミュニケーションの量が増加します
- コードレビューのための非常に優れたメカニズムであるプルリクエストは実行できません
- 他の開発者がその間にすでにmasterブランチをプルしている可能性があるため、一般的にコミットをスカッシュ/ git履歴を変更することはできません
新機能が本番環境にプッシュされる前にテスト環境にデプロイできる独自の開発ブランチが必要であることを彼に説明します。
そうでなければ、あなたは半分完成した機能の永久的な状態にいます。半分完成した機能を本番環境にデプロイすることはできないため、masterブランチで直接作業している場合、バグ修正を含め、他の人の変更が本番環境に移行する前に、他の全員があなたの機能を完了するのを待つ必要があります。
機能に独立したブランチを使用するということは、それぞれの新しい機能を他の機能とは独立してテストおよび展開できることを意味します。
- マスターは、稼働中の最終バージョンである本番ブランチを反映する必要があります。
- マスターで直接作業することは、バグを作成した場合、コミットを元に戻す/削除/リセットする以外に「戻る」ためのオプションがないことを意味します。これは作業のクリーンな方法ではなく、新しいコードの一部を失う可能性があります大丈夫だった。
- もちろん、開発の非常に最初の段階では、おそらくmasterで直接作業を開始できますが、何かを提供した後、公開、完全、機能しているバージョンに触れないように、開発、テスト、または実験ブランチを使用する必要があります。
マスターは解放できる可能性があります。限目。マスターで半分完成した作業があってはなりません（機能フラグで無効にしない限り）。
そうは言っても、一部のチームがフローを複雑にしているのを見たことがあります。
マスターへの統合時にPRを使用しないのは間違いです。開発者は統合がいつ発生するかを選択する権限がないためです。
単一の開発ブランチがもたらす価値はほとんどありません。通常それは物事を複雑にするだけです。多くの機能ブランチは多くの価値をもたらします。
各環境（dev、test、prod）にブランチを作成するのは誤りです。これはgitの範囲外であり、リリースパイプラインで処理する必要があります。まったく同じビルドをすべての環境にデプロイする必要がありますが、各環境にブランチがある場合は不可能です。
機能が非常に大きい場合、1日か2日で完了できないため、機能ブランチへのすべての作業は別々のブランチにあり、PRと統合する必要があります。
私たちの同僚の1人は、masterブランチで直接変更を行うことに非常に満足しており、いくつかの会話にもかかわらず、これを変更する可能性は低いようです。
これは私にもっと問題があると信じさせます。マスターであるかどうかに関係なく作業することは、製品をリリースする方法、何をいつリリースするかに関するより大きな哲学の一部です。
したがって、「マスターで作業することはできません」と並行して、機能のテストを行っていますか。他の人の作業をテストしていますか？他の人のコードをレビューしていますか。受け入れおよび統合テスト。
上記のどれも持っておらず、 "do git"を実行するだけの場合は、masterで作業することもできます。
その他の回答では、マスターで直接作業しないことのさまざまな利点（孤立した機能、常にマスターで出荷可能なコードなど）がすでに言及されています。
私には別の問題があるようです。明らかに、開発プロセスはありません。開発プロセスはすべての開発者によって合意または使用されています（または問題の開発者はプロセスを完全に無視しています）。
マスターにマージされる機能ブランチはありますか、または異なるリリースブランチがありますか、それともまったく異なるプロセスを使用していますか？
「マスターブランチを使用しない」では不十分です。
まず、gitでは、すべてのpullは文字通り分岐操作であり、すべてのPushはマージであることを指摘しておきます。開発者のマシンのmasterは、共有する中央リポジトリのmasterとは完全に別のブランチであり、技術的な観点からは同等の立場にあります。ローカルバージョンの名前をupstreamなどに変更して、目的に適したものにする場合があります。
多くの組織は、同僚よりもブランチをより効果的に使用していると考えているため、これを指摘します。実際には、ブランチに追加の名前を作成する以外に何もしていませんが、いずれにしても履歴には保存されません。同僚が1つのアトミックコミットで機能をコミットしている場合、機能ブランチのマージコミットと同じくらい簡単に取り消すことができます。機能ブランチの大部分は非常に短期間であり、とにかく頻繁にマージされるはずです。
とはいえ、彼の働き方の主な欠点は2つあります。まず、未完成の機能でのコラボレーションが非常に難しくなります。ただし、コラボレーションが必要なときにだけブランチを作成することは難しくありません。
次に、マージ前のレビューが非常に難しくなります。この点で、あなたは実際に彼を説得する必要はありません。 github、gerrit、gitlabなどのツールを採用できます。すべてのマージに対して、プルリクエストコードのレビューと合格した自動テストが必要です。このようなことをしていなければ、率直に言って、gitを最大限に活用していないので、同僚がその可能性を理解していないのも不思議ではありません。
ブランチで直接作業することに関する「悪い習慣」はありません。しかし、あなたはあなたのプロセスを最もよくサポートするものを決定する必要があります：
質問1：マスターはソフトウェアの現在のリリース状態を表す必要がありますか？次に、グローバル開発ブランチを導入し、リリース開発の最後に開発をマージする必要があります。
質問2：コードレビュープロセスが必要ですか？次に、プルリクエストを介してマスター（または、開発している場合は開発）にマージされる「機能ブランチ」が必要です。
質問3：まだプロダクション（またはテスト）に公開されるべきではない中間コードの状態を他の開発者と共有する必要がありますか？これは、複数の開発者が機能を開発する場合に当てはまります。次に、「機能ブランチ」を紹介します。