Feature Branch Workflow を調べる
Feature Branch Workflow を支える中心的なアイデアは、すべての機能開発は、メイン ブランチではなく専用ブランチで行わなければならない、というものです。
このカプセル化により、メイン コードベースを妨げることなく、複数の開発者が特定の機能に関する作業を行うことが容易になります。 これは、破損したコードがメイン ブランチに含まることは決してないことも意味し、継続的な統合環境にとっては非常に大きな利点となります。
機能開発をカプセル化することで、pull request を使用することもできます。これは、ブランチに関するディスカッションを開始する方法です。 これにより、他の開発者は、公式プロジェクトに統合する前に、機能を使用してサインアウトすることができます。 または、機能の途中で行き詰まった場合は、同僚からの提案を求める pull request を開くことができます。
pull request を使うと、チームがお互いの作業について非常に簡単にコメントできるようになります。 また、機能ブランチは中央リポジトリにプッシュできます (プッシュする必要があります)。 これにより、公式コードに触れずに、他の開発者と機能を共有できます。
メインは唯一の「特別な」ブランチであるため、中央リポジトリにいくつかの機能ブランチを保存しても問題は発生しません。 これは、全員のローカル コミットをバックアップする便利な方法でもあります。
リリース ブランチ ワークフロー
機能ブランチのワークフローに加えて、Git ブランチ ワークフローで一般的に使用されるもう 1 つの戦略は、リリース ブランチ戦略です。 この戦略には、リリースの準備専用ブランチの作成が含まれます。 リリース ブランチは通常、安定した機能ブランチから作成され、十分にテストおよび検証されたコードのみが含まれていることを確認します。 作成されると、リリース ブランチは追加のテスト、バグ修正、および安定化作業を行って、デプロイ用にコードベースを準備します。 リリース ブランチを使用すると、リリース関連のアクティビティを継続的な機能開発から分離でき、今後のリリースを最終処理および洗練するための制御された環境が提供されます。 リリース ブランチで必要なすべての調整と検証が行われた後、チームのリリース プロセスに応じて、メイン ブランチにマージされるか、運用環境に直接デプロイされます。 リリース ブランチ戦略は、チームが継続的な開発のために安定したメイン ブランチを維持しながら、リリース アクティビティの調整の複雑さを管理するのに役立ちます。
トランクベースの開発ワークフロー
トランクベースの開発ワークフローでは、中央リポジトリが想定されており、メインは正式なプロジェクト履歴を表します。 開発者は、ローカルのメイン ブランチに直接コミットするのではなく、新しい機能に関する作業を開始するたびに新しいブランチを作成します。 機能ブランチには、new-banner-images や bug-91 のように、わかりやすい名前を付ける必要があります。 各ブランチに、明確で範囲を絞り込んだ目的を与えることがその考え方です。
Git では、メイン ブランチと機能ブランチの間に技術的な区別はないため、開発者は機能ブランチに対する変更を編集、ステージング、コミットすることができます。
分岐を作成する
プロジェクトに取り組んでいるときは、いつでもさまざまな機能やアイデアが進行中です。その中には、準備ができていないものとそうでないものがあります。 ブランチは、このワークフローの管理を支援するために存在します。 プロジェクトでブランチを作成すると、新しいアイデアを試すことができる環境を作成できます。
新しい機能や修正のためのブランチを作成するだけでなく、リリース ブランチ ワークフローに従うチームは、リリースの準備専用のブランチも作成します。 通常、これらのリリース ブランチは、十分にテストおよび検証されたコードを確実に含めるために、安定した機能ブランチから派生します。 作成されると、リリース ブランチは追加のテスト、バグ修正、および安定化作業を行って、デプロイ用にコードベースを準備します。
コミットの追加
ブランチが作成されたら、変更を開始します。 ファイルの追加、編集、削除を行うたびに、コミットを行い、それらをブランチに追加します。
各コミットを追加することで、機能ブランチで作業している間の進行状況が追跡されます。
また、コミットによって作業のすぐわかる履歴も作成され、他のユーザーがそれを見てあなたの作業の内容や理由を把握できます。
各コミットには、特定の変更が行われた理由を説明するコミット メッセージが関連付けられています。
さらに、各コミットは個別の変更ユニットと見なされます。 バグが見つかった場合や別の方向に移動する場合に、変更をロールバックすることができます。
コミット メッセージは重要です。特に、Git は変更を追跡し、サーバーにプッシュされた後にそれらをコミットとして表示するためです。
明確なコミット メッセージを記述することで、他のユーザーが簡単にフォローし、フィードバックを提供できるようになります。
Pull request を開く
pull request により、コミットについてのディスカッションが開始されます。 これらは基礎となる Git リポジトリと密接に統合されているため、要求を受け入れるとどのような変更がマージされるかを、だれでも正確に確認できます。
開発プロセス中は、次の場合にいつでも Pull Request を開くことができます。
- コードをほとんど、またはまったく使用せずに、スクリーンショットや一般的なアイデアを共有したいと考えています。
- 行き詰まっており、ヘルプやアドバイスを必要としています。
- だれかがあなたの作業を確認する準備が整いました。
Pull Request メッセージで @mention システムを使用して、特定のユーザーやチームが廊下にいる場合でも、10 タイム ゾーン離れている場合でも、フィードバックを求めることができます。
Pull Requests は、プロジェクトに貢献し、共有リポジトリに対する変更を管理するのに役立ちます。
Fork＆Pull モデルを使用している場合、プル要求を使用すると、プロジェクトメンテナーに検討する変更について通知することができます。
共有リポジトリ モデルを使用している場合、Pull Requests は、提案された変更がメイン ブランチにマージされる前に、提案された変更に関するコード レビューと会話を開始するのに役立ちます。
コードについて話し合ってレビューする
Pull Request が開いた後、変更をレビューするユーザーまたはチームから質問やコメントが寄せられる場合があります。
おそらく、コーディング スタイルがプロジェクトのガイドラインと一致していない、変更に単体テストがない、すべて見栄えがよい、prop が整っている、といったものです。
Pull Request は、この種の会話を促進してキャプチャするように設計されています。
コミットに関するディスカッションとフィードバックを検討して、引き続きブランチにプッシュすることができます。
何かを行い忘れたというコメントを誰かが投稿するかもしれません。または、コードにバグがある場合は、ブランチで修正して変更をプッシュすることができます。
Git では、統合された pull request ビューで受け取る可能性がある新しいコミットと、すべてのフィードバックが表示されます。
pull request コメントは Markdown で書き込まれるので、画像や絵文字を埋め込んだり、事前に書式設定されたテキスト ブロックやその他の軽量な書式設定を使用したりできます。
配置
Git を使用すると、メインにマージする前に、環境内の最終テストのためにブランチからデプロイできます。
アプリケーションが pull request し、ブランチがテストに合格したら、変更をデプロイして検証できます。 ブランチで問題が発生した場合は、既存のメインをデプロイすることでロールバックできます。
Merge
変更を検証したら、次はコードをメイン ブランチにマージします。
マージされると、Pull Requests では、コードに対する変更履歴のレコードが保持されます。 これらは検索可能であるため、だれでも時間を遡って、決定が行われた理由と方法を理解することができます。
pull request のテキストに特定のキーワードを組み込むことで、イシューをコードに関連付けることができます。 Pull Request がマージされると、関連する問題が閉じられる可能性もあります。
このワークフローは、ビジネス ドメイン機能セットに重点を置くブランチを整理および追跡するのに役立ちます。
Git Forking Workflow や Gitflow Workflow などの他の Git ワークフローはリポジトリに焦点を当てており、Git Feature Branch Workflow を使用してブランチ モデルを管理できます。