混乱のないチームワーク: Git の分岐戦略を理解する

序章

Git は、ソフトウェア開発におけるバージョン管理システムの事実上の業界標準となっています。まずは、Git とは何か、そしてどのように始めるかについての私の記事を読んでください。読んだことがありますか？素晴らしい、さあ、行きましょう! 好むと好まざるにかかわらず、Linus Tovalds が作成したこのツールは廃止されません。したがって、分散チームが Git をどのように使用するか、またそのためにどのような分岐戦略を選択する必要があるかについて話すことは理にかなっています。これは取るに足らない質問ではありません。これまで一緒に働いたことのない新しい開発チームを編成する場合、多くの場合、最初に決定すべきことの 1 つが分岐戦略です。そして、ある戦略が他の戦略よりも優れていることを証明するために、口から泡を吹く人もいます。そこで、それらに関する一般的な情報をいくつかお伝えしたいと思います。

分岐戦略は必要ですか?

それらは確かに必要なものです。とても必要です。なぜなら、チームが何かに同意しない場合、各チームメンバーは自分の望むことを行うからです。

• どの支店でも働いています
• 他の任意のブランチにマージする
• いくつかのブランチを削除する
• 新しいものを作成する
• そのため、チームの各メンバーは管理されていないフローで行動することになります。

そのため、以下に検討すべき 3 つの戦略があります。さあ行こう！

GitHub フロー

奇妙なことに、この分岐戦略は GitHub で好まれています:) これには一連のルールが付属しています:

1. master ブランチのコードは壊れてはいけません。いつでも展開できるように準備しておく必要があります。つまり、プロジェクトのビルドとサーバーへのデプロイを妨げるコードをそこに配置してはなりません。
2. 新しい機能に取り組む予定がある場合は、master ブランチに基づいて新しい機能ブランチを作成し、意味のある名前を付ける必要があります。コードをローカルにコミットし、変更をリモート リポジトリの同じブランチに定期的にプッシュします。
3. 作業の準備が完了し、master ブランチにマージできると思われる場合 (または、確信が持てないが、完了した作業についてのフィードバックが必要な場合)、プル リクエストを開きます (プル リクエストについては こちら を参照してください) 。
4. プル リクエストの新機能が承認されると、master ブランチにマージできます。
5. 変更が master ブランチにマージされたら、すぐにサーバーにデプロイする必要があります。

GitHub Flow によると、修正であれ新機能であれ、何か新しい作業を開始する前に、master に基づいて新しいブランチを作成し、それに適切な名前を付ける必要があります。次に、実装に向けた作業が始まります。同じ名前でリモート サーバーにコミットを常に送信する必要があります。すべての準備が完了したと判断したら、master ブランチへのプル リクエストを作成する必要があります。次に、「承認」をクリックする前に、少なくとも 1 人、できれば 2 人がこのコードを確認する必要があります。通常、プロジェクトのチーム リーダーと 2 番目の人が必ず確認する必要があります。その後、プル リクエストを完了できます。GitHub Flow は、プロジェクトの継続的デリバリー (CD)を推進することでも知られています。これは、変更が master ブランチに入力されると、すぐにサーバーにデプロイされる必要があるためです。

GitFlow

以前の戦略 (GitHub Flow) は、本質的にはそれほど複雑ではありません。ブランチには、マスター ブランチとフィーチャー ブランチの 2 種類があります。しかし、GitFlow はもっと深刻です。少なくとも、上の図を見ればそれが明らかになるでしょう :) では、この戦略はどのように機能するのでしょうか? 一般に、GitFlow は 2 つの永続ブランチと数種類の一時ブランチで構成されます。GitHub Flow のコンテキストでは、master ブランチは永続的で、その他は一時的です。 永続的なブランチ

• マスター: 誰もこの枝に触れたり、何かを押したりしてはなりません。この戦略では、マスターは実稼働環境 (つまり、実サーバー上) で使用される最新の安定バージョンを表します。
• 開発: 開発ブランチ。不安定になる可能性があります。

開発は 3 つの補助的な一時ブランチを使用して行われます。

1. 機能ブランチ — 新しい機能の開発用。
2. リリース ブランチ — プロジェクトの新しいバージョンのリリースの準備に使用します。
3. Hotfix ブランチ — 実際のサーバー上で実際のユーザーが発見したバグを迅速に修正します。

機能ブランチ

機能ブランチは、新しい機能のために開発者によって作成されます。これらは常に開発ブランチに基づいて作成する必要があります。新しい機能の作業が完了したら、開発ブランチへのプル リクエストを作成する必要があります。明らかに、大規模なチームでは、一度に複数の機能ブランチを持つことができます。GitFlow 戦略の説明の冒頭にある図をもう一度見てください。

リリースブランチ

必要な新機能のセットが開発ブランチで準備ができたら、製品の新しいバージョンのリリースの準備をすることができます。開発ブランチに基づいて作成されたリリース ブランチがこれに役立ちます。リリース ブランチを使用する場合は、すべてのバグを見つけて修正する必要があります。リリース ブランチを安定させるために必要な新しい変更も、開発ブランチにマージし直す必要があります。これは、開発ブランチを安定させるためにも行われます。テスターがブランチが新しいリリースに十分安定していると判断した場合、そのブランチは master ブランチにマージされます。その後、このコミットに対してバージョン番号が割り当てられたタグが作成されます。例を確認するには、戦略の冒頭の図をご覧ください。そこにタグ 1.0 が表示されます。— これはプロジェクトのバージョン 1.0 を示す単なるタグです。そして最後に、Hotfix ブランチがあります。

ホットフィックスブランチ

Hotfix ブランチは、新しいバージョンを master ブランチにリリースすることも目的としています。唯一の違いは、それらのリリースが計画されていないことです。リリースされたバージョンにバグが入り込み、運用環境で発見される場合があります。iOS を例に挙げると、新しいバージョンがリリースされるとすぐに、リリース後に見つかったバグを修正した大量のアップデートが配信されます。したがって、早急にバグを修正し、新しいバージョンをリリースする必要があります。この図では、これはバージョン 1.0.1 に対応します。この考え方は、実際のサーバー (または、「本番環境」または「本番環境」と言う言い方をします) でバグを修正する必要がある場合でも、新機能の開発を停止する必要はないということです。Hotfix ブランチは現在運用環境で実行されているものを表すため、master ブランチから作成する必要があります。バグ修正の準備ができ次第、マスターにマージされ、新しいタグが作成されます。リリース ブランチを準備するのと同じように、ホットフィックス ブランチもその修正を開発ブランチにマージして戻す必要があります。

フォークのワークフロー

フォーク ワークフローでは、開発には 2 つのリポジトリが関係します。

1. すべての変更がマージされる元のリポジトリ。
2. フォークリポジトリ。これは、元のリポジトリのコピーであり、元のリポジトリに変更を加えたい別の開発者が所有しています。

ここまでだと少し奇妙に思えますよね？オープンソース開発にすでに出会ったことがある人なら誰でも、このアプローチにはすでに精通しています。この戦略には次の利点があります。元のブランチでの共同開発の権限を付与せずに、フォーク リポジトリで開発を行うことができます。当然のことながら、元のリポジトリの所有者は、提案された変更を拒否する権利を有します。または、それらを受け入れてマージします。これは、元のリポジトリの所有者と、製品の作成を支援したい開発者の両方にとって便利です。たとえば、Linux カーネルへの変更を提案できます。Linus がそれらが意味があると判断した場合、変更が追加されます (!!!)。

フォークワークフローの例

使用したいライブラリがある場合、GitHub 上でフォーク ワークフローが適用されます。バグがあり、完全に使用することができません。問題を十分に深く掘り下げて解決策を知ったとします。フォーク ワークフローを使用すると、ライブラリの元のリポジトリで作業する権限がなくても問題を解決できます。開始するには、 Spring Framework などのリポジトリを選択する必要があります。右上隅にある「フォーク」ボタンを見つけてクリックします。これには時間がかかります。その後、元のリポジトリのコピーが個人アカウントに表示され、それがフォークであることが示されます。これで、このリポジトリを通常どおり操作して、master ブランチに変更を追加できるようになります。すべての準備ができたら、元のリポジトリへのプル リクエストを作成できます。これを行うには、[新しいプル リクエスト]ボタンをクリックします。

どの戦略を選択するか

Git は、さまざまなプロセスや戦略を使用して作業できる、柔軟で強力なツールです。しかし、選択肢が増えれば増えるほど、どの戦略を選択するかを決めるのは難しくなります。すべての人にとって唯一の答えがないことは明らかです。すべては状況次第です。ただし、これに役立つガイドラインがいくつかあります。

1. 最初に最も単純な戦略を選択するのが最善です。必要な場合にのみ、より複雑な戦略に移行してください。
2. 開発者向けに、ブランチ タイプをできるだけ少なくする戦略を検討してください。
3. さまざまな戦略の長所と短所を検討し、プロジェクトに必要な戦略を選択してください。

Git の分岐戦略について言いたかったのはこれだけです。ご清聴ありがとうございます :) GitHub でフォローしてください。私は仕事で使用するさまざまなテクノロジーやツールを使用した作品を頻繁に投稿しています。