GitHubフロー：Githubワークフロー

Gitフローの問題

私はあちこちを旅して、人々にGitを教えています。最近実施したほとんどすべてのレッスンとセミナーで、彼らはgit-flow についてどう思うかと尋ねました。 私はいつもこのアプローチは素晴らしいと思うと答えました-彼は無数の可能なワークフローがあるシステム（Git）を取り、多くの開発者にかなり簡単な使用に適した実証済みの柔軟なプロセスを文書化しました。 このアプローチも少し標準になるため、開発者はこの標準化されたワークフローに精通しながら、プロジェクトからプロジェクトへ、そして会社から会社へと移動できます。



ただし、git-flowにも問題があります。 機能ブランチがmaster ではなく 開発 から離れているという事実、または修正プログラムの処理方法に敵意を表明した人々の意見をよく耳にしますが、これらの問題は比較的小さいものです。



私にとって、 git-flowの最大の問題の1つは、その複雑さでした。これは、ほとんどの開発者やワーキンググループが実際に必要とするものを超えています。 その複雑さにより、ワークフローをサポートするアシスタントスクリプトがすでに出現しています。 これ自体はクールですが、問題はアシスタントがGit GUIからではなくコマンドラインから機能することであり、困難なワークフローを本当によく学ぶ必要がある同じ人たちは、すべてのステップを手動で実行する必要があるためです- これらの人々 にとって 、システムはコマンドラインから使用するのに十分便利ではありません。 これが大きな問題になります。



これらの問題はすべて、はるかに単純なワークフローに従うことで簡単に克服できます。 githubではgit-flowは使用しません。 私たちのワークフローは、Gitへのよりシンプルなアプローチに基づいています（常にそうなっています）。



そのシンプルさにはいくつかの利点があります。 第一に、人々はそれを理解しやすいため、ロールバックを必要とするミスをより早く、より少ない頻度で（またはまったく）使用し始めます。 さらに、プロセスをフォローするのにラッパースクリプトは必要ないため、GUI （など）を使用しても問題は発生しません。

Githubワークフロー

それでは、なぜgithubでgit-flowを使用しないのですか？ 主な問題は、継続的な変更の導入を採用していることです。 git-flowワークフローは、主に新しいコードのリリースを支援するために作成されました。 また、「リリース」はありません。これは、コードが運用環境（メインの作業サーバー）に毎日（時には1日に数回）到着するためです。 同じチャットルームでこのためのコマンドをボットに送信し、CIの結果を表示できます（統合テスト）。 各従業員が作業しやすいように、コードとその実装のテストプロセスをできる限りシンプルにするよう努めています。



このような新製品の頻繁な導入には、多くの利点があります。 数時間ごとに発生する場合、多数の主要なバグを引き起こすことはほとんど不可能です。 小さな欠陥が発生しますが、それらは非常に迅速に修正できます（そして、修正が順番に実装されます）。 通常、「ホットフィックス」を作成するか 、通常のプロセスから何らかの形で逸脱する必要がありますが、私たちにとっては通常のプロセスの一部に過ぎません。Githubワークフローでは、ホットフィックスと小さな機能に違いはありません。



変更を継続的に実装することのもう1つの利点は、あらゆる種類の問題に迅速に対応できることです。 セキュリティ問題の報告に対応したり、新機能に対する小さな（しかし興味深い）リクエストを実行することができますが、通常の（または大規模な）サイズの機能の開発に関連する変更を行う場合にも同じプロセスが機能します。 プロセスは同じで、非常に簡単です。

どうやってやるの

では、githubのワークフローとは何ですか？

• masterブランチのコンテンツは常にデプロイ可能です。
  
  
• 新しいもので作業を開始し、 マスターブランチから新しいブランチを作成します。名前はその目的に対応しています（たとえば、 「 new-oauth2-scopes 」）。
  
  
• このブランチにローカルでコミットした後、作業を​​サーバー上の同じ名前のブランチに定期的に送信します。
  
  
• フィードバックやヘルプが必要なとき、またはマージの準備ができているブランチが見つかったら、マージリクエストを送信します。
  
  
• 他の人が機能をレビューして承認したら、ブランチを マスター ブランチにマージできます。
  
  
• マスターブランチに新しいコードが補充されたら、すぐに実稼働環境に実装できます 。

これがワークフロー全体です。 非常にシンプルで生産的で、かなり大きなワーキンググループで機能します。現在35人がGithubで働いており、そのうち15人か20人が同じプロジェクト（github.com）で同時に働いています。 ほとんどの開発チーム（競合を引き起こす可能性のある同じコードのロジックを同時に使用するグループ）のサイズは同じか、これよりも小さいと思います。 特に、迅速で一貫した実装を行うのに十分なほど進歩的なグループ。



それでは、各ステップを順番に見ていきましょう。

masterブランチのコンテンツは常にデプロイ可能です。

一般に、これはシステム全体で唯一の厳格なルールです。 ブランチは1つだけで、常に特別な意味があり、 マスターと呼んでいます。 私たちにとって、これは、このブランチのコードが実稼働環境で実装されるか、最悪の場合、数時間以内に実装されることを意味します。 このブランチがいくつかのコミットをロールバックすることは非常にまれです（作業をキャンセルするため）：問題が発生した場合、コミットからの変更はキャンセルされるか、完全に新しいコミットで問題が修正されますが、ブランチ自体はほとんど戻りません。



マスターブランチは安定しています。 本番コードを実装するか、それに基づいて新しいブランチを作成することは常に、常に安全です。 マスターからテストされていないコードを受け取ったり、アセンブリを壊した場合、開発チームの「社会的契約」に違反しているので、それについて猫をかき集めてください。 各ブランチは当社でテストされ、結果はチャットルームに送信されます。したがって、ローカルでテストしていない場合は、ブランチを（1回のコミットでも）サーバーにプッシュし、すべてのテストが成功した場合はJenkinsが報告するまで待つことができます。

マスター ブランチからの分岐。名前が目的に対応する新しいブランチ

新しい何かに取り組みたいときは、安定したブランチマスターから目的に応じた名前の新しいブランチを作成します。 （たとえば、現在のGithubコードには、 「 user-content-cache-key 」、 「 submodules-init-task 」、 「 redis2-transition 」というブランチがあります。）この名前にはいくつかの利点があります。 たとえば、 fetchコマンドを送信するだけで、他の人が取り組んでいるトピックを確認できます。 さらに、しばらくブランチを残して、後でブランチに戻ると、それが何であったかを名前で覚えやすくなります。



Githubにブランチのリストがあるページにアクセスすると、最近作業したブランチ（およびおおよその作業量）を簡単に確認できるため、これは素晴らしいことです。







これは、現在の状態を大まかに推定した将来の機能のリストのようなものです。 このページを使用しない場合は、クールな機能があることを知っておく必要があります。現在選択したブランチに固有の作業が行われたブランチのみが表示され、最新のブランチが表示されるようにソートされます仕事は上からでした。 好奇心を持ちたい場合は、「比較」ボタンをクリックして、正確に結合された差分とこのブランチに固有のコミットのリストを確認します。



さて、これを書くと、リポジトリに未接続のコードを持つ44のブランチがありますが、先週にコードを受け取ったのはそのうちの9または10だけであることも明らかです。

名前付きブランチコードをサーバーに常に送信する

git-flowとのもう 1つの大きな違いは、ブランチをサーバーに継続的にプッシュすることです。 実装の観点から見ると、 マスターブランチについてのみ本当に心配する必要があるため、 プッシュは誰も困惑させたり、壊したりしません。 マスターではないものはすべて、作業中のコードです。



これにより、ラップトップの紛失またはハードドライブの障害が発生した場合に安全コピーが作成されます。 これは、開発者間の絶え間ない情報交換をサポートし、さらに重要です。 単純なgit fetchコマンドを使用すると、現在誰もが作業しているTODOのリストを取得できます。

$ git fetch remote: Counting objects: 3032, done. remote: Compressing objects: 100% (947/947), done. remote: Total 2672 (delta 1993), reused 2328 (delta 1689) Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done. Resolving deltas: 100% (1993/1993), completed with 213 local objects. From github.com:github/github * [new branch] charlock-linguist -> origin/charlock-linguist * [new branch] enterprise-non-config -> origin/enterprise-non-config * [new branch] fi-signup -> origin/fi-signup 2647a42..4d6d2c2 git-http-server -> origin/git-http-server * [new branch] knyle-style-commits -> origin/knyle-style-commits 157d2b0..d33e00d master -> origin/master * [new branch] menu-behavior-act-i -> origin/menu-behavior-act-i ea1c5e2..dfd315a no-inline-js-config -> origin/no-inline-js-config * [new branch] svg-tests -> origin/svg-tests 87bb870..9da23f3 view-modes -> origin/view-modes * [new branch] wild-renaming -> origin/wild-renaming
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、誰でも（Githubブランチリストページで）他の誰が作業しているかを確認できます。コードを分析し、開発者を支援するかどうかを決定できます。

いつでもマージリクエストを作成する

GitHubには、 マージ要求と呼ばれるすばらしいコードレビューシステムがあります 。 開発者がそれを十分に認識していないのではないかと思います。 多くの人々は、オープンソースコードの通常の作業でそれを使用します。プロジェクトを分岐し、コードを更新し、プロジェクト所有者にマージ要求を送信しました。 ただし、このシステムは内部コード検証の手段としても使用できるため、使用しています。



実際、マージ要求としてではなく、ブランチを表示および議論する手段として使用します。 GitHubは、同じプロジェクト（オープンまたはプライベート）のあるブランチから別のブランチへのマージリクエストの送信をサポートしているため、リクエストでは、「このコードを受け入れてください」だけでなく、「このコードのヒントまたは概要が必要です」と言うことができます。







この図では、JoshがBrianにコードを調べるように依頼し、コードの1行についてアドバイスを与えていることがわかります。 以下に、JoshがBrianの考慮事項にどのように同意し、それらに応答するためにコードを補充するかを示します。







最終的に、コードはまだテスト段階にあることがわかります。まだ実装の準備ができているブランチではありません。実際にマスターにマージして実装に送信するずっと前に、マージ要求を使用してコードを確認します。



機能やブランチでの作業が滞り、ヘルプやアドバイスが必要な場合、または開発者であり、デザイナーも作業を確認する必要がある場合（またはその逆）、またはコードがほとんどない（またはまったくない）場合でも、スクリーンショットと一般的なアイデアのいくつかの構成、その後、マージ要求を開きます。 Githubシステムでは、ユーザーに@言及することでディスカッションにユーザーを追加できるため、特定の人物からのレビューまたは応答が必要な場合は、リクエストでその人物を言及できます（上記のJoshの方法を参照）。



マージリクエストでは、結合されたdiffの個々の行、個々のコミット、またはリクエスト全体全体についてコメントすることができ、レプリカのコピーが単一のディスカッションを形成するため、これは素晴らしいことです。 ブランチにコードを補充し続けることもできます。そのため、 誰かがコード内のエラーや忘れられた機会を指摘した場合、同じブランチに修正を加えることができ、GitHubはディスカッションに新しいコミットを表示するので、このようにブランチで作業できます。



ブランチが長すぎて、ブランチ内のコードがmasterブランチのコードと矛盾していると感じた場合、 masterからブランチにコードを追加して作業を続けることができます。 マージ要求の説明またはコミットのリストで、 masterから取得したコードでブランチが最後に更新されたのは簡単にわかります。







ブランチでの作業が完全に完全に終了し、実装の準備ができたと感じたら、次のステップに進むことができます。

クエリレビュー後にのみマージ

マスターブランチで直接作業することはありませんが、名前が付けられたブランチの作業は、完了したと判断した直後にマージしません。まず、会社の他の従業員から承認を得ようとします。 通常は「+1」 または絵文字 、または「：shipit：」というコメントの形式をとりますが、ブランチを見るために誰か他の人を連れて行く必要があります。







承認が得られ、ブランチがCIに合格すると、 マスターにマージして実装することができます。 この時点で、マージ要求は自動的に閉じられます。

レビュー直後の実装

最後に、作業は終了し、その成果はmasterブランチにあります。 これは、今すぐ実装を開始しなくても、他の従業員のブランチの基礎となり、次の実装（数時間以内に行われる可能性が高い）がビジネスに斬新さをもたらすことを意味します。 そして、 他の誰かがあなたのコードを実行し、それに苦しんでいる（コードが何かを壊した場合）ことに気付くのは非常に不愉快なので、人々はマージの結果の安定性を注意深くチェックし、結果自体を実装するのが自然です。



hubotという名前のキャンプファイヤーボットは、従業員の指示に従ってコードを挿入できます。 hubot deploy githubをチャットのプロダクションコマンドに送信するだけで十分です。コードはプロダクションに移動し、必要なすべてのプロセスを（ダウンタイムなしで）再起動します。 これがGithubでどのくらいの頻度で発生するかを自分で判断できます。







ご覧のとおり、6人の異なる人（1人のサポートと1人のデザイナーを含む）が1日に20回以上コードを実装しました。



上記のすべてを、1行の変更を含む1つのコミットでブランチに対して行いました。 このプロセスは、シンプルでわかりやすく、スケーラブルで強力です。 同じことは、2週間の作業を必要とする50のコミットを含む機能ブランチで、約10分で1つのコミットで行うことができます。 プロセスは非常に単純であり、負担が少ないため、シングルコミットの場合でもその必要性は迷惑ではありません。そのため、人々はめったに個々のステップをスキップしたりスキップしたりしません-それが重要であるほど小さくて取るに足らない変更でない限り。



私たちのワークフローは、強力でありながら非常にシンプルです。 GitHubは非常に安定したプラットフォームであり、問​​題が発生した場合は迅速に対応し、新しい機能が急速に実装されているという点に多くの人が同意すると思います。 ワークフローの速度とシンプルさを向上させたり、ステップ数を削減したりする品質や安定性の面で妥協はありません。

おわりに

Git自体を理解するのはかなり難しいです。 必要以上に複雑な作業プロセスでも使用されている場合、問題は日々の過度の理性的な努力で終わります。 私は、あなたのグループの仕事に適した可能な限りシンプルなシステムの使用を、そしてこのシステムが機能しなくなるまで、常に提唱します。 避けられない場合にのみ複雑さを追加してください。



公式コードリリースを長い間隔（リリース間で数週間から数か月）で準備し、修正プログラムを作成し、以前のバージョンのブランチをサポートし、このようなまれなコードリリースのために必要な他の作業を行う必要があるワーキンググループの場合、それは理にかなっていますgit-flow 、それを使用することを強くお勧めします。



毎日の生産を更新し、機能を継続的にテストおよび実装するコード配信を中心に構築されたグループの場合、GitHub Flowなどのよりシンプルなワークフローをお勧めします。