masterブランチをそのまま維持することは、共同作業に不可欠ではありませんか？
私はgitとのコラボレーションに関する有用な記事をたくさん読んだ。多くのすべきこと、すべきでないことなどがあります。たとえば、 プルリクエストレビューの誤りトップ1 とgitワークフローに関するすばらしい記事 完璧なコードレビュープロセス は、すばらしい方法です。それを行うの。有名な 成功したGit分岐モデル とかなり似ています。私は、特にgitを使用したルール、または必要に応じて倫理についても特にこれを気に入っています GitLabフローの11のルール 。
しかし、私が理解していないのは、ほとんどすべての記事で、私がそれらすべての中で最も重要なルールであることがわかっているものについて言及している理由です。 を常に実行して、メインブランチ（通常はマスター）が完全に機能していることを確認してください。私が知っている最悪のことは、機能ブランチで作業しているときに、自分のブランチが機能しなくなったことを理解するためだけにマスターにマージすることです。または、マスターが期待どおりに機能していないために、開発者が新機能の開始から行き詰まるようにします。私の目には、コードレビューと組み合わせたテストがこれをカバーするはずです。しかし、私はこの特定のルールに言及している記事をめったに見ません。
ですから、私が間違っているのは、masterブランチをそのままにしておくことは、私が思うようにチーム開発にとってそれほど重要ではないのですか？それらの記事の著者はそれを言及するのを忘れましたか？
リンクした4つの記事すべてをスキャンすると、「マスター」を完全に保つためのルールは非常に基本的であり、言及する価値がないと見なされているという観点から書かれているようです。
実際、このルールは「マスター」だけに適用されるわけではありません。 共同作業のために共有されるすべてのブランチチームの2人以上のユーザー間、またはビルドサーバーにプッシュされるブランチに適用されます。ただし、特定の機能ブランチで単独で作業している場合は、コードを完全にコンパイル可能にして、すべての単体テストをエラーのない状態に保つことは重要ではありません（ただし、少なくとも、できるだけ頻繁にその状態に到達するため）。
なぜそれがより頻繁に明示的に言及されていないのですか？私は推測することしかできませんが、ここで最もよく推測するのは、チームで働いたことがあり、そのルールに従わない人はすべて、他のチームメイトのフィードバックによってすぐにそれを見つけ出すことです。他の人の作業を妨げるコードをチェックインした場合、後者の人はおそらく満足せず、前者にもっと注意するように言います。
以下も参照してください。
メインブランチ（通常はマスター）を常に確認するには、常に完全に機能します。
仰るとおりです。
プルリクエストが受け入れられる前に厳格なコードレビュー（3人！）を行わなければならない外部の請負業者として、会社の従業員が一度も実行したことがない（たとえば、露骨なnull参照-ビルドに合格した）壊れたコードをチェックインするのは腹立たしいです。しかし明らかに吹き飛ばされる）マスターに。マスターをブランチにマージすると、マスターを修正できないため、それらのバグを突然修正しています。プルリクエストを確認するまで、CI/CDパイプライン全体が動かなくなります。
私の目には、コードレビューと組み合わせたテストがこれをカバーするはずです。
（私が扱っているものと比較して）より良い解決策は、マスターを直接操作することができず、プルリクエストを介してのみ更新できるようにすることです。
ただし、ビルドに問題がないことを100％保証することは不可能です。ビルドは成功するかもしれませんが、単にテストされなかった実行時エラーがあるかもしれません。テストは、カバーするように書かれたものだけをカバーできます。
したがって、問題がマスターになる可能性は常にあります。そして、これらのケースでは、開発者（または少なくともリード開発者）がマスターにアクセスして、CI/CDパイプラインを滞らせている問題をすばやく修正できることは理にかなっています。
プルリクエストでこれらの修正を強制できますか？承知しました。しかし、数秒かかる修正のための追加のオーバーヘッドは非常に大きく、プレッシャーが高すぎてそれを待つことができない場合があります。
破損を修正するためにマスターへのプッシュアクセスを誰かが持っていることは理にかなっています。しかし、マスターに直接プッシュすることは誰にとっても当たり前のことではありません。
そうは言っても、これは少し奇妙なことだと私は知っていますが、マスターがビルド可能な状態である必要がない周辺のケースがあります：
- まだ初期フレームワーク（プロジェクトなど）をセットアップしている場合、何日もマージの競合が発生するため、複数のブランチで作業することはほとんど意味がありません。通常、空のアプリケーションフレームワークをセットアップするのは1人だけです。
- 大規模な構造変更を行っており、CI/CDパイプラインがその変更が完了するまで保留されることが合意されている場合。
- 別のブランチでこれを行う方が良いように聞こえますが、他の人が、すぐに劇的に変更されるコードベースに機能を実装し続けることはほとんど意味がないと考えてください。 Gitは、機能を新しいアーキテクチャとマージする方法を途中まで把握できない場合もあります。
- ただし、フレームワークの変更をマスターに段階的に（まだ壊れている）プッシュすると、少なくとも全体のビルドがまだ完了していない場合でも、既に完了しているアーキテクチャの新しい部分で機能の開発を開始できます。
- これはもちろん例外的な状況です。誰も決してwant積極的に開発しながらアーキテクチャをこれほど劇的に変更するべきではありません。
反対票を集める危険にさらされて、私に別の視点を提供させてください。
私は作業コードをプッシュするだけでよいという考えに同意しません。説明しているだけです
開発のさまざまな段階で、さまざまな目的があります。
開発の初期段階での一般的な経験則は、「早期にリリースし、頻繁にリリースする」ことです。フィードバックを取得する良い方法-ビルドを壊す愚かな間違いでも-完全に機能していない場合でも、コードを共同編集者が利用できるようにすることです。これには間違いなく、この特定のプロジェクトが進行中の作業であり、開発者がビルドの健全性を維持することを約束しないことを相互に理解する必要があります。これは、CI/CDが配置されているすべての設定で問題になることに注意してください。
「パニックモード」の開発では、他の機能が壊れていても、セキュリティ修正を（ある程度）プッシュできます。繰り返しになりますが、共同作業者の間には、厄介な優先事項があり、いくつかの重要な技術的負債は、中心的な問題が解決された後、すぐに対応する必要があるかもしれないことを理解する必要があります。
リスクを助長する組織（有名なFacebookなど）があり、ビルドを中断して（おそらくエキサイティングで中毒性のある）新しい機能を提供できます。うまくいけば、再び、これは、誰もが一般的なソフトウェア開発の規範からのそのような逸脱を認識しなければならない状況です。
ここでの一番下の行は、実際には共同作業者は常に十分に理解され、理想的には十分に文書化された合意コミットされたコードから何を期待するかについて、そしておそらくこのようなシナリオで追加の通信チャネル。