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

導入

Git は、ソフトウェア作成におけるバージョン管理の事実上の業界標準となっています。git とは何か、そしてその開始方法について学ぶには、まずそれに関する私の記事を読んでください。読んだことがありますか？素晴らしい、次に進みましょう! 好むと好まざるにかかわらず、Linus Towalds が作成した楽器が引退することはありません。したがって、分散チームが git でどのように機能するか、またそのためにどのような分岐戦略を選択するかについて話すことは理にかなっています。そして、これはまったく無駄な質問ではありません。多くの場合、互いに協力したことのない開発者からなる新しいチームが編成される状況では、最初に決定する必要があることの 1 つが分岐戦略です。そして、ある戦略が他の戦略よりも優れていることを証明するために口から泡を立てる人もいるでしょう。したがって、それらが一般的にどのようなものであるかについての情報をお伝えしたいと思います。

分岐戦略は必要ですか?

しかし、それらは必要であり、今でも必要とされています。なぜなら、チーム内で同意できない点があると、全員が自分のやりたいことをすることになるからです。

• 自分が希望する支店で働く。
• 彼が望む他のブランチにマージします。
• いくつかのブランチを削除します。
• 新しいものを作成します。
• など、チーム メンバーのそれぞれが制御されていない流れの中にいます。

そこで、以下に3つの戦略をご紹介します。行く！

GitHub フロー戦略

分岐戦略は、それがどれほど奇妙であっても、GitHub では好まれています :) それには、従う必要がある 一連のルールが添付されています。

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

GitHub Flow によると、修正であれ新機能であれ、何か新しいことに取り組み始める前に、master に基づいて新しいブランチを作成し、それに適切な名前を付ける必要があることがわかりました。次に、実装に向けた作業が始まります。同じ名前のリモート サーバーにコミットを常にプッシュする必要があります。すべての準備が完了したことを理解したら、master ブランチでプル リクエストを作成する必要があります。次に、少なくとも 1 人、できれば 2 人がこのコードを見て [承認] をクリックする必要があります。通常、プロジェクトのチーム リーダーと他の誰かがそれを確認する必要があり、その後、プル リクエストを完了できます。GitHub Flow は、プロジェクトの継続的デリバリー (CD)を推進することでも知られています。これは、master ブランチに変更が加えられた場合、変更を直ちにサーバーにデプロイする必要があるためです。

GitFlow戦略

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

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

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

1. 機能ブランチ - 新しい機能を開発するため。
2. リリース ブランチ - プロジェクトの新しいバージョンのリリースを準備します。
3. ホットフィックス ブランチは、実際のサーバー上で実際のユーザーによってすでに発見されている欠陥に対する迅速な解決策です。

機能ブランチ

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

リリースブランチ

必要な数の新機能が開発ブランチで準備されたら、製品の新しいバージョンのリリースを準備できます。これにはリリース ブランチが役立ちます。これは開発ブランチに基づいて作成されます。リリース ブランチを操作しながら、すべての欠陥を見つけて修正する必要があります。リリース ブランチを安定させるために必要な新しい変更もすべて、開発にマージし直す必要があります。これはブランチを安定させて発展させるために行われます。テスターがブランチが新しいリリースに十分安定していると判断すると、そのブランチは master ブランチにマージされます。次に、このコミットにタグが作成され (タグ: 詳細については、こちらを参照してください)、バージョン番号が割り当てられます。例として、戦略の冒頭の図を見てください。つまり、タグ 1.0 は プロジェクトのバージョン 1.0 を示すラベルにすぎません。そして最後はブランチのホットフィックスです。

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

Hotfix ブランチは、マスターでの新しいバージョンのリリースも目的としています。唯一の違いは、このリリースは計画されていないことです。欠陥がリリースに達し、本番環境ですでに発見されている状況があります。たとえば、iOS の場合、新しいバージョンがリリースされるとすぐに、リリース後に発見された欠陥を修正した大量のアップデートが配信されます。この点で、この欠陥を早急に修正し、新しいバージョンをリリースする必要があります。この図では、これはバージョン 1.0.1 に対応します。この考えは、実際のサーバー上の欠陥を修正する必要がある瞬間に、新しい機能の開発が停止しない可能性があるということです (「運用中」と言うように、これも英語の単語 Production のコピーです)。Hotfix ブランチは実稼働環境で動作する状態を表すため、master ブランチから作成する必要があります。欠陥に対する解決策の準備が整うとすぐに、それがマスターにマージされ、新しいラベルが作成されます。リリース ブランチを準備するのと同じように、ホットフィックス ブランチはそのソリューションを開発ブランチにマージする必要があります。

フォークワークフロー戦略

フォーク ワークフロー戦略の一環として、開発は 2 つのリポジトリが存在する方法で実行されます。

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

ここまで見ると少し奇妙に思えますよね？すでにオープンソース開発に出会ったことがある人にとっては、このアプローチはすでに馴染みのあるものです。この戦略には次の利点があります。元のリポジトリでの共同開発の権利を付与せずに、フォーク リポジトリで開発を実行できます。もちろん、元のリポジトリの所有者には、提案された変更を拒否する権利があります。あるいは同意して殺すか。これは、元のリポジトリの所有者と、製品の作成に参加したい開発者の両方にとって便利です。たとえば、Linux カーネルへの変更を提案できます。Linus がそれらが意味があると判断した場合、変更が追加されます (!!!)。

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

GitHub上で使いたいライブラリがある場合にForking Flowを利用します。十分な使用を妨げる欠陥があります。問題を十分に掘り下げて解決策を知ったとします。フォーク ワークフロー戦略を使用すると、元のライブラリ リポジトリで作業する権限を付与せずに、この問題を解決できます。開始するには、リポジトリ (例: Spring Framework core )を選択する必要があります。右上隅にあるフォーク ボタンを見つけてクリックします。これに はしばらく時間がかかります。その後、この元のリポジトリのコピーがディレクトリに表示されます。個人アカウント。これはフォークであることを示します。 その後、通常どおりこのリポジトリを操作し、master ブランチに変更を追加し、すべての準備ができたら、元のリポジトリへのプルリクエストを作成します。これを行うには、[新しいプル リクエスト]ボタン をクリックします。

どの戦略を選択するか

Git は、幅広いプロセスと戦略を使用して作業できるようにする、柔軟で強力なツールです。しかし、選択肢が増えれば増えるほど、今どの戦略を選択するかを決めるのは難しくなります。明らかに、すべてに当てはまる万能の答えはありません。すべては状況次第です。ただし、これに役立ついくつかの推奨事項があります。

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

git の分岐戦略についてお話ししたかったのはこれだけです。ご清聴ありがとうございます :) 私の GitHub アカウントを購読してください。私は仕事で使用するさまざまなテクノロジーやツールで自分の作品をそこに投稿することがあります。

役立つリンク

• GitHub フロー: Git と GitHub を使用する最良の方法
• GitHub でのプル リクエスト、または他の人のプロジェクトに変更を加えるにはどうすればよいですか
• GitHub:プルリクエストについて
• 差別化された継続的インテグレーション、デリバリー、デプロイメント
• Git の基本:タグの操作
• Habr: Git の成功した分岐モデル