プロ向けのGitワークフロー：優れたGitガイド

公開: 2022-03-11

Gitは、バージョン管理だけでなく、コラボレーションとリリース管理でもプロジェクトをサポートできます。 Gitワークフローパターンがプロジェクトをどのように支援または妨害するかを理解することで、プロジェクトのGitプロセスを効果的に評価および適応させるための知識が得られます。

このガイド全体を通して、一般的なGitワークフローに見られるソフトウェア開発プロセスパターンを分離します。これらの知識は、開発チームに参加、作成、または成長する際の方向性を見つけるのに役立ちます。特定のタイプのプロジェクトまたはチームの長所と短所は、私たちが調査するワークフローの例で強調表示されるため、シナリオに適したものを選択できます。

これはGitの使い方の紹介ではありません。すでにそこにこれのための素晴らしいガイドとドキュメントがあります。アプリケーション開発チームでの経験があり、ワークフローの障害、統合の内破、またはgit-tastrophesに直面したことがある場合は、このGitワークフローガイドの恩恵を受けることができます。これらのパターンは、将来これらの状況を回避する方法に光を当てる可能性があります。

コラボレーション

Gitプロセスの観点から、コラボレーションは多くの場合、ワークフローの分岐に関するものです。コミットツリーをどのように絡み合わせるかを前もって考えることは、統合のバグを最小限に抑え、リリース管理戦略をサポートするのに役立ちます。

統合ブランチ

貢献のコレクションを単一のエンティティとして本番環境に展開することに取り組んでいるソフトウェア開発チームとの統合ブランチを使用します。これは、機能を個別に展開することに焦点を当てているチームとは対照的です。多くの場合、チームは後者を実行したいと思うかもしれませんが、実際的な制限により、作業をグループ化するプロセスが課せられ、チームは前者を実行することになります。したがって、実際のGitの使用状況を確認して、このタイプのコラボレーションを使用することでメリットが得られるかどうかを確認してください。パターン。

このワークフローパターンは、複数のブランチを統合するリスクが十分に高く、結合された貢献を全体としてテストする必要がある場合に役立つステージングポイントです。

統合ブランチは通常、主要な機能と、一緒にデプロイされるいくつかの小さな貢献で構成されます。開発チームのプロセス（Q＆Aや受け入れテストなど）に統合ブランチを配置します。マイナーコミットをプッシュして本番環境に近づけてから、環境ブランチまたはリリースブランチ（以下で説明）を使用してデプロイの準備をします。

別の主要な機能を統合ブランチにマージする前に、統合ブランチの貢献を次のリリースステージにマージする必要があることに注意してください。そうしないと、完了のさまざまな段階で機能を混在させることになります。これにより、準備ができているものを解放する能力が阻害されます。

トピックブランチ

チームは、コミットツリーを簡単に読み取れる状態に保つか、個々の機能を元に戻すことが重要な場合は、トピックブランチを使用することをお勧めします。トピックブランチは、コミットが（強制プッシュを使用して）上書きされ、構造がクリーンアップされ、機能コミットに縮小される可能性があることを示します。

トピックブランチは、多くの場合、個々の寄稿者が所有しますが、チームが機能を開発するための指定されたスペースにすることもできます。他の寄稿者は、このタイプのブランチではいつでもコミットツリーが書き直される可能性があることを知っており、ローカルブランチとの同期を維持しようとすべきではありません。

Gitワークフローでトピックブランチを利用しないと、リモートブランチにプッシュするコミットに固執することに制限されます。新しいコミットツリーをリモートブランチに強制的にプッシュすると、同期するブランチの整合性の維持に依存している他の貢献者を怒らせる可能性があります。

このワークフローパターンを気付かずにすでに使用している可能性がありますが、チーム間で定義のセットを共有して、チームの背後にあるプラクティスを強化することは価値があります。たとえば、ブランチ名の前にブランチ作成者のイニシャルを付けるという規則が、トピックブランチを示すのに役立つ場合があります。いずれにせよ、内部の慣習を決定するのはあなたのチーム次第です。

パブリックリポジトリでトピックブランチを使用しないでください。ローカルブランチを、コミットツリーが書き直されたトピックブランチと同期した人には、無数の競合が発生します。

フォーク

オープンソースプロジェクトは、このGithub独自の機能を使用して繁栄します。 フォークは、オリジンリポジトリブランチに直接プッシュするよりも、強制されたゲートウェイを使用してリポジトリメンテナに権限を与えますが、さらに重要なことに、コラボレーションを容易にします。ワフー！

プライベートリポジトリのフォークを作成することもニーズに合っているというシナリオに気付くかもしれません。フォークリポジトリの寄稿者に対してオリジンリポジトリを読み取り専用に設定し、プルリクエストをローリングすると、オープンソースコミュニティが体験するのと同じ利点が得られます。さまざまな組織のチームは、コミュニケーションとプロジェクトポリシーの順守のためのプラットフォームとなるフォークを使用して効果的に作業できます。

フォークワークフローパターンは、2つのリポジトリ間の単一の統合ポイント（プルリクエスト）を使用して、チームが慣れている方法で作業するための独自のスペースをチームに提供します。プルリクエストの説明では、過剰な通信が不可欠です。プルリクエストが発行される前に、チームは別々のコミュニケーションストリームを持っていました。すでに行われた決定を強調することで、レビュープロセスがスピードアップします。

もちろん、フォークワークフローの利点の1つは、アクセス許可が下にカスケードされるため、コメントをオリジンリポジトリの寄稿者に送信できることです。オリジンリポジトリの観点からは、フォークが不要になったときにフォークを削除するためのコントロールがあります。

このパターンを利用するために、リクエストのフォークとプルを容易にするツールを使用していることを確認してください。これらのツールはGithubに限定されません。他の一般的な選択肢はBitbucketとGitlLabです。しかし、これらの機能（または同様の機能）を備えたGitワークフローホスティングサービスは他にもかなりあります。自分に最適なサービスを選択してください。

チームの各メンバーにプライベートリポジトリのフォークを使用しないでください。フォークされたリポジトリが多数あると、複数のメンバーが同じ機能ブランチで共同作業を行うことが困難になる可能性があり、可動部分の数が非常に多いため、これらのリポジトリすべての同期を維持するとエラーが発生しやすくなります。オープンソースプロジェクトには、このオーバーヘッドを軽減するオリジンリポジトリへのプッシュアクセスを備えたコアチームメンバーがいます。

クローン

一般的なアウトソーシング戦略は、複数のソフトウェア開発者が埋めることができるプロジェクトに貢献する「席」を持つことです。契約時間を提供するためにリソースパイプラインを管理するのはアウトソーシング会社次第です。彼らが直面する問題は、各クライアントのプロジェクトのために開発者のプールをどのようにオンボード、トレーニング、および維持するかです。

プロジェクトのリポジトリのクローンを使用すると、外部委託されたチームが貢献を管理し、ポリシーを実施し、知識の共有を活用するための分離されたトレーニングとコミュニケーションの場がレイアウトされます。これらはすべて、クライアントの開発チームの監視下から行われます。コントリビューションが標準に達し、メインリポジトリの準備ができたら、オリジンリポジトリのリモートブランチの1つにプッシュして、通常どおりに統合できます。

一部のプロジェクトは、リポジトリに貢献するために、コーディング規則と定義されたGitワークフロー標準に従うことに大きな期待を寄せています。ロープを習得するまで、この環境での作業は困難な場合があります。チームとして協力して、両者の時間を最適化してください。

クライアントのリポジトリのホストされたコピーを許可なく作成しないでください。契約上の合意に違反している可能性があります。この方法がクライアントとのプロジェクトに役立つことを事前に確認してください。

リリース管理

コラボレーションからリリースまでのステップは、各チームの開発プロセス内のさまざまなポイントから開始されます。通常、複数のリリース管理Gitパターンを使用することは望ましくありません。チームが効果的に提供できるようにする、可能な限り単純なワークフローが必要です。

環境ブランチ

ソフトウェア開発プロセスは、本番環境に展開する前の品質保証を支援するために、いくつかの環境でサポートされている場合があります。 環境ブランチは、このプロセスのステージを模倣します。各ステージはブランチに対応し、コントリビューションはパイプラインでこれらを通過します。

これらのプロセスで実行されているチームでは、多くの場合、パイプラインの各ステージ（「QA」、「ステージング」、「本番」など）にアプリケーション環境が設定されています。これらの場合、インフラストラクチャは、次の人に移動する前に、機能の承認または生産準備が整っていることの意味の一部（たとえば、探索的テスト、QA、受け入れテスト）の貢献を担当する担当者をサポートするために用意されています。ステージ。これにより、サインオフトンネルを通過する過程を記録するためのGitワークフローを使用して、要件に照らして展開、テスト、および評価するための独自の場所が提供されます。

プロセスの各段階にブランチを持つことは、ユニットとしてのリリースに向けて取り組むことができる小さなチームにとっては問題ありません。残念ながら、このようなパイプラインは簡単にボトルネックになったり、束になってギャップを残したりする可能性があります。 Gitプロセスをインフラストラクチャに結合します。これにより、機能の立ち上げが必要で、両方のプロセスを拡張する必要がある場合に問題が発生する可能性があります。

最初に他のパターンの長期的な利点を考慮せずにこのパターンを使用しないでください。

リリースブランチ

貢献のコレクションを連続したスプリントのユニットとして本番アプリケーションにプッシュするチームは、リリースブランチが適していることを見つけることができます。

「本番環境に対応した」コミットのコレクションには、リリースブランチでマイナーなバグ修正が加えられています。統合ブランチを使用して、コミットツリーをリリースブランチに移動する前に、機能を組み合わせてテストします。リリースブランチの責任を、本番アプリケーションにデプロイする前の最終チェックに限定します。

リリースブランチは、寿命が短いという点で環境ブランチとは異なります。リリースブランチは、必要な場合にのみ作成され、コミットツリーが本番環境にデプロイされた後に破棄されます。

リリースブランチをソフトウェア開発ロードマップに結合しないようにしてください。事前に決定された計画に従うように制限すると、計画されたすべての機能が本番環境で使用できるようになるまで、リリースの展開が遅れます。リリースブランチを作成する前にロードマップにバージョン番号を割り当てないことで、本番環境の機能をリリースブランチに配置して展開できるようにすることで、これらのタイプの遅延を軽減できます。

リリースブランチ名にバージョン番号の命名規則を使用して、リポジトリのどのバージョンが本番環境にデプロイされているかを明確にします。

リリースブランチではなく、マスターブランチをデプロイします。マスターブランチとマージする前にリリースブランチにマイナーな修正を加えることを奨励するには、マージが発生した後にトリガーするマスターブランチのGitフックを使用して、更新されたコミットツリーを本番環境に自動的にデプロイします。

特定の時点で1つのリリースブランチのみが存在できるようにすることで、複数のリリースブランチを相互に同期させるオーバーヘッドを回避できます。

同じリポジトリで複数のチームが作業しているリリースブランチは使用しないでください。リリースブランチは短命ですが、最終チェックに時間がかかりすぎると、他のチームのリリースが妨げられます。チームが別のチームのリリースブランチに便乗していると、バグが発生し、両方のチームに遅延が発生する可能性があります。以下のタイムスタンプ付きのリリースパターンを見てください。これは、貢献者の数とグループが多いほど効果的です。

タイムスタンプ付きリリース

インフラストラクチャの制限があるアプリケーションは、通常、トラフィックの少ない時間帯に展開をスケジュールします。プロジェクトが展開の準備ができている機能の定期的なキューに直面している場合は、タイムスタンプ付きのリリースを使用することでメリットが得られる可能性があります。

タイムスタンプ付きリリースは、デプロイメントプロセスに依存して、本番環境にデプロイされたマスターブランチの最後のコミットにタイムスタンプタグを自動的に追加します。トピックブランチは、展開を待つためにマスターブランチにマージされる前に、機能を開発プロセスに通すために使用されます。

タイムスタンプタグには、実際のタイムスタンプと、それが展開を表すことを示すラベルを含める必要があります（例： deployed-201402121345 。

マスターブランチのコミットツリー内にタイムスタンプタグの形式でデプロイメントメタデータを含めると、本番アプリケーションにリリースされたリグレッションのデバッグに役立ちます。問題の原因を突き止めた担当者は、実稼働アプリケーションにデプロイされているすべてのラインについて多くのことを知っている可能性はほとんどありません。最後の2つのタグでgit diffコマンドを実行すると、最後にデプロイされたコミットと、問題の解決に役立つコミットの作成者のスナップショットをすばやく取得できます。

タイムスタンプ付きのブランチは、表面に表示される以上のものです。キューに入れられた機能の展開を記録するための単純なメカニズムには、それを駆動するための驚くべき量の優れたプロセスが必要です。このプロセスは、拡張可能であり、貢献者の小さなチームでもうまく機能するプロセスです。

このGitワークフローパターンが本当に効果的であるためには、マスターブランチが常にデプロイ可能である必要があります。これはチームにとって異なることを意味する可能性がありますが、基本的にすべてのコミットは、マスターブランチに到達する前にプロジェクト開発プロセスを経ている必要があります。

マスターブランチに着陸する新しいコミットは、1日に複数回発生します。これは、開発プロセスを経て、この期間中にマスターブランチと同期されていないトピックブランチの問題です。残念ながら、このようなシナリオでは、マージの競合が誤って処理されると、マスターブランチにリグレッションが発生する可能性があります。

トピックブランチとマスターブランチの間でマージの競合が発生した場合は、リモートマスターブランチを更新する前に、新しいバグが発生するリスクについてチームと話し合う必要があります。リグレッションが発生する可能性があることに疑いがある場合は、トピックブランチを品質保証プロセスに戻し、マージの競合を解決できます。

統合のバグを減らすために、リポジトリの関連部分で作業している開発者は、トピックブランチをマスターブランチとマージおよび同期するのに最適なタイミングで共同作業を行うことができます。統合ブランチは、関連するトピックブランチからの競合を解決するためにもうまく機能します。これらは、展開が保留されているマスターブランチのキューにマージされる前に、テストプロセスを通過する必要があります。

多くの貢献者がいるソフトウェア開発プロジェクトは、実用的かつ効率的なアプローチでコラボレーションとリリース管理プロセスに対処する必要があります。タイムスタンプ付きのリリースを使用して取得するコミットツリー上の追加のメタデータは、本番環境の問題に対応する準備をしているチームの先見性へのポインターです。

バージョンブランチ

本番環境で実行するだけでなく、他のユーザーが独自のホストアプリケーションに使用するリポジトリがある場合、バージョンブランチを使用すると、アプリケーションの開発の最先端に留まらない、または留まらないユーザーをサポートするためのプラットフォームをチームに提供できます。。

バージョンブランチを使用するリポジトリには、アプリケーションのマイナーバージョンごとに1つのブランチがあります。メジャー、マイナー、およびパッチのバージョンは、セマンティックバージョニングのドキュメントで説明されています。バージョンブランチは通常、命名規則に従って「安定」という単語を含め、アプリケーションバージョンからパッチ番号を削除します。たとえば、エンドユーザーに目的と信頼性を明確にするために2-3-stableです。

Gitタグは、アプリケーションのパッチバージョン番号まで適用できますが、バージョンブランチはそれほどきめ細かくはありません。バージョンブランチは、サポートされているマイナーバージョンの最も安定したコミットを常に指します。

セキュリティパッチまたはバックポート機能の必要性が生じた場合は、サポートしている古いアプリケーションバージョンで機能するために必要なコミットをまとめて、それぞれバージョンブランチにプッシュします。

リポジトリの複数のバージョンをサポートしていない限り、バージョンブランチを使用しないでください。

概要

チームの規模が変わった場合、またはプロジェクトが継続的な評価を通じてプロセスを開発する場合は、Gitプロセスの評価も忘れないでください。このチュートリアルのパターンを出発点として使用して、Gitワークフローの正しさの道を進むのに役立ててください。

このガイドのパターンは、分散バージョン管理システムを自分に合わせて調整するための先見性を身に付けるのに役立ちます。 Gitワークフローについて詳しく知りたい場合は、Gitflow、Github Flow、そして最も重要なgit-scmドキュメントを確認してください。

関連：強化されたGitフローの説明