チームに適したGitワークフローと分岐モデルを選択する方法

Gitは、ほとんどすべてのソフトウェア開発の中心となるバージョン管理システムです。Gitは、作成したコードへの変更を保存および追跡するために使用されます。チームで作業する場合、ビジネスに役立つシームレスなワークフローを用意することは、急速に成長するために重要です。

より良いリポジトリ編成、より迅速な開発

Jenkinsのような使いやすい自動化パイプラインの出現により、多くの企業が継続的インテグレーションとデリバリー（CI / CD）の実装を開始し、開発者からの変更がリポジトリにマージされることが多く、通常は製品を毎週ではなく毎週配信します。毎週。毎月のスケジュール。

この速度は、特にGitに関しては、組織に大きな負担をかけます。同じブランチに変更をコミットしようとしている人が50人いる場合  master 、マージの競合が頻繁に発生するという問題が発生します。

幸い、Gitにはブランチを作成し、コードをマージするタイミングを選択する機能があります。これを使用して、すべてのチームが開発を整理する必要があります。Gitワークフローを制御することで、少なくともあなたとあなたのチームメートが新しいGitの問題をグーグルで検索する時間を無駄にすることを防ぐことができます。

ブランチの機能と開発

Gitブランチが取り組んでいる2つの大きな問題があります。それは、内部コマンドの同期を維持することと、パブリックリリースを維持することです。

Gitでブランチを開始すると、ではなく、そのブランチに対して新しいコミットが行われmasterます。これは、特定の機能またはバグ修正の個々の進捗状況を追跡するのに役立ちます。たとえば、各ブランチは、Jira、Trello、Github Issues＆Projectsなどのかんばんサービスの課題で説明されている機能を実装できます。

master ブランチのマージは通常、プルリクエストを使用して行われます。これは、コマンドがブランチからのプルをリクエストし、feature すべてのユーザーの変更を統合するGithubなどのホストされたGitソリューションの機能です。これは、チェーンを上に移動する前にブランチが適切に機能していることを確認するためにQAと単体テストを行うチームにとって非常に役立ちます。

もう1つの問題は、リリースの管理です。不正なコミットによって破損する可能性があるため、最新の内部開発ビルドのコピーをクライアントに送信したくない場合があります。

この問題を解決するために、多くのチームはリリースに別のブランチを使用し、新しいバージョンをリリースするときにのみそのブランチをマージします。これにより、リリース間の開発ブランチのバックグラウンドで複数のコミットが可能になります。

このモデルのもう1つの利点は、本番ブランチで個別にコミットできることです。これにより、次のリリースの準備が整う前に問題の修正が提供される可能性があります。

主な開発

分岐戦略によって、提供されているツールをどのように使用するかが正確に決まります。さまざまなタイプのチーム向けに設計されたさまざまな分岐戦略があります。

高速道路ベースの開発は、チームプログラミングのあるべき姿に近いものです。つまりmaster 、実行可能な製品を迅速にリリースするためのブランチでの高速イテレーションです。チームは、通常は数日以内に存続する短期間の機能ブランチを作成し、多くの場合、に直接コミットしmasterます。

master これは、他のすべてをサポートする太い木の幹のように、ブランチをリポジトリ全体で最もアクティブで便利なブランチにするため、「トランク」と呼ばれます。すべての開発はこのブランチに焦点を合わせています。このブランチは簡単かつ迅速に習得でき、優れた開発者エクスペリエンスを提供します。

リリースの準備が整うと、リリースごとに新しいバージョン管理されたブランチが作成されます。これにより、リリースがから分離されmaster、LTSリリースの修正を追加または選択するのにも役立ちます。

これには、特に小規模なチームにとって多くの利点があります。リポジトリ全体の書き込み権限を知っていて信頼している数人の上級開発者と協力している場合は、変更をできるだけ早く統合することで、開発を大幅にスピードアップできます。結局、これにより、絶え間ないプルリクエストとマージに関連するほとんどすべての官僚主義が排除されますが、チームとの単純なコミュニケーションは依然としてお互いを追い詰めるために必要であり、相手が何に取り組んでいるかを常に知る必要があります。

ただし、これは規律と優れた開発者に依存するため、優れた組織ではありません。これは、製品をすばやくリリースしたり、既存のプロジェクトをすばやく繰り返したりするのに非常に便利ですが、プロジェクトにジュニア開発者を追加したり、オープンソースの共同作業者を増やしたりすると、すぐに欠陥が現れ始めます。

従来のGitフロー

「GitFlow」は、多くのチームで機能するワークフローです。これは、単純なバックボーン開発ワークフローよりも複雑ですが、オープンソースプロジェクトや多くのチームメンバーがいる大規模なプロジェクトに多くのメリットをもたらします。

Git Flowブランチ戦略では、機能ブランチは長持ちし、毎日の統合の主な焦点です。チームは、本番環境の準備が整うまで機能に取り組み、その後、プルリクエストプロセスを経て承認を得ます。同時にいくつもの機能が存在する可能性があります。これには、より最近のmaster コミットにリベースする必要があるほど長く存続する機能も含まれます。

Git Flowを使用すると、ほとんどの開発者がに直接マージする権限を持たdevelopず、確かにとマージする権限がないため、アクセスがより制限され、master変更を加えるための主要な方法としてブランチを作成する必要があります。

Git Flowは当然、プルリクエストプロセス中に適切なコードレビューのための時間を残します。これにより、常に変化するバックボーンブランチではなく、PR、リベース、およびマージを使用して競合を処理できます。これらのフォークはサードパーティから提供される可能性があるため、これはオープンソースにとって意味がありますが、大規模なチーム環境や、多くのコンポーネントを備えたモノリシック製品を開発するチームにとっても意味があります。

このワークフローの重要な機能の1つは、リリーステンプレートです。新しいリリースの時期になると、準備のために別のブランチが作成されます。ここで最終的なバグ修正とパッチが作成され、実際のmaster ブランチにプッシュされ、リリースをビルドするためのタグが付けられます。

主な違いは、このmaster ブランチがと一緒に維持されることdevelopです。developリリースブランチからのコミットは、修正と同様ににマージされます。develop これにより、安定しているときにリリースが作成される最新のブランチが常に作成されます。

master この分離により、最新のリリースにマージする前にリリースする必要のあるマイナーなバグ修正の管理が容易になります。リリースブランチは機能ブランチとほとんど同じように機能しますが、安定としてマークされるという追加のボーナスがあります。

もちろん、絶え間ないプル、リベース、およびマージ要求は大変な作業であり、高速にしようとしている場合は面倒な場合があります。ただし、静的型付けや単体テストと同様に、最終的には整理してスムーズに実行する価値があります。

あなたにぴったりのものを選択してください

結局のところ、それはすべて優れたチームのエチケットに関するものであり、あなたのチームは、派手な図よりも線のようなGitの履歴をうまく処理できます。プロジェクトが小規模な場合、または個人的な趣味の場合は、厳格なGit基準に固執することで、利益よりも害を及ぼす可能性があります。

ただし、Gitで問題が発生した場合は、バックボーンまたはGitFlowの開発を試すことができます。少なくとも、リポジトリの構成を理解することは、統合プロセスを改善するのに役立ちます。