もう一度GitFlowベースワードを見たので、私はびっくりして、GitHub Flowと呼ばれるブランチを操作するためのよりシンプルで問題の少ないスキームの説明を翻訳することにしました。 デフォルトでそれを使用するのは理にかなっています、克服できない状況の場合にのみ他のものに移動します。

ブランチを作成する

1つのプロジェクトに取り組んでいる間、さまざまな改善を並行して実装できます。 それらのいくつかは準備ができていますが、そうでないものもあります。 分岐により、このワークフローを管理できます。

プロジェクトにブランチを作成すると、新しいアイデアを試すことができる環境が作成されます。 別のブランチで行われた変更は、トランク（マスターブランチ）には影響しません。 これにより、ブランチが実際に準備が整うまで他のブランチに影響を与えないことを知って、変更を安全に実験してコミットできます。

分岐はgitの基本概念です。 GitHub Flow全体はそれに基づいており、それによると、1つのルールのみがあります。トランク内にあるものはすべて安定しており、いつでもデプロイできる状態にあることが保証されています。



したがって、新しいブランチをトランクから正確に作成することが非常に重要です。 そして、ブランチの名前は、他の人がその中で何が起こっているのかを理解できるように、説明的なものにすることでした。 いくつかの例： refactor-authentication



、 user-content-cache-key



、 make-retina-avatars



。

変更をコミットする

ブランチを作成したら、変更を開始します。 ファイルを追加、編集、または削除するときは、ブランチで新しいコミットを作成することを忘れないでください。 凝視のシーケンスは、最終的に、他の人があなたがしたこととその理由を理解することができるように、あなたのタスクに取り組んでいる透明な歴史を形成します。

各コミットには関連メッセージがあります。これは、変更が行われた理由の説明です。 各コミットは、個別の変更単位とも見なされます。 これにより、エラーが検出された場合、または別の方向に進むことにした場合に、変更をロールバックできます。

他の開発者があなたの意図をすぐに理解し、加えられた変更がどれだけそれらに対応するかを評価できるので、コミットの明確な説明は非常に重要です。 そのため、それらからのフィードバックはより速くなり、より便利になります。

トランクからブランチにできるだけ頻繁に変更を注ぎ、常に関連性を維持し、リバースマージの準備を整えます。 ブランチの開発者は、そこに記録された変更を最もよく知っているので、マージの競合の可能性を解決することは、ブランチ開発者の権利と義務です。

マージリクエストを開く

プルリクエストは、コミットのディスカッションを開始します。 それらは基本的なgitリポジトリと密接に統合されているため、リクエストを受け入れた場合、トランクにどのような変更が加えられるかを誰でも明確に理解できます。

開発プロセス中はいつでもマージリクエストを開くことができます。

• コードがほとんどまたはまったくないが、スクリーンショットや一般的なアイデアを共有したい場合
• あなたが立ち往生し、助けやアドバイスが必要なとき
• 誰かがあなたの仕事をチェックする準備ができたら

マージリクエストメッセージで@GitHubメンションシステムを使用すると、特定の人々またはチーム全体からフィードバックを要求できます。



マージリクエストは、単一のリポジトリ内だけでなく、フォーク間でコードを転送するためのツールとしても役立ちます。 あるリポジトリのブランチを別のリポジトリのブランチにマージするリクエストを作成し、さらに先に進みます。

コードを確認して議論する

マージ要求を開いた後、チームは変更を検討し、質問をしてコメントを残します。 おそらく、コーディングスタイルは受け入れられている契約と一致しません。 単体テストが欠落している可能性があります。 そして、おそらくすべてがよさそうで、満足のいくものではありません。 リクエストは、提案された変更に議論を正確に集中させ、それらと一緒にグループ化することを目的としています。

もちろん、発生した議論に照らして、更新をスレッドに補充し続けることができます。 何かをするのを忘れた、またはコードにエラーがあると言われた場合、ブランチでそれを修正し、サーバーにプッシュ（プッシュ）できます。 GitHubは、新しいコミットとそれらに対する追加のフィードバックをすべてマージ要求の同じ統一された表現で表示します。

マージリクエストへのコメントでは、マークダウンマークアップを使用できます。これにより、画像や顔文字を挿入したり、フォーマット済みのテキストブロックやその他の軽量なフォーマットを使用したりできます。

バトルチェックイン

マージ要求をチェックしてテストに合格した後、ブランチを戦闘環境に展開して、最終的に動作することを確認できます。 ブランチで問題が発生した場合、代わりに機能が保証されたメイントランクを展開することにより、ブランチをすばやくロールバックできます。 ブランチはまだどこにも注がれていないため、他のブランチへの影響はまだ除外されており、問題のあるコードは他のブランチを壊すことはできません。 本当に準備が整うまでタスクの作業を続けることができます。

注ぎ込む

変更が戦闘でテストされたので、コードをメイントランクに注ぎます。

トランクにマージすると、ブランチからのすべての変更を含むコミットが作成されます。 他のコミットと同様に、検索および「タイムトラベル」に使用できます。

マージリクエストのテキストに特定のキーワードを含めることにより、コードに問題を関連付けることができます。 ブランチがトランクに注入されると、関連する問題もクローズします。 たとえば、 closes #32



というフレーズを入力すると、リポジトリの課題番号32が閉じられます。 詳細については、 関連記事を参照してください 。

頻繁なリリースが不可能な場合

連続配信を練習していない場合、各ブランチを個別にトランクに持ってくることは難しいかもしれません。 この場合、準備ができていると思われるブランチのみを注ぐ統合ブランチを作成します。 ブランチの1つを変更すると問題が発生する場合、統合ブランチはいつでも再構築できますが、問題のあるブランチは含まれなくなります。 これにより、計画されたタスクのいずれかが予定日に完全に準備されていなかった場合でも、リリーススケジュールを中断することはありません。

GitFlowとの違いは何ですか？

GitFlowには、現在開発中のすべてのブランチがマージされる追加のdevelop



ブランチがあります。 develop



はリリース前に「安定化」 develop



必要があります。これは、リリースの延期または「コメント付きリリース」のいずれかにつながることがよくあります。

GitLab Flowとの違いは何ですか？

GitLab Flowでは、最初にブランチをメイントランクに注ぎ、次にテスト、戦闘、およびその他の環境に展開します。 リリースに問題があることが判明し、ロールバックする必要がある場合、GitFlowの場合のように、非常に問題のあるトランクの「リバースマージ」または「安定化」が必要になることがあります。