このすみエンジニアブログスマートフォン用の表示で見るこのすみエンジニアブログ2018-04-29git-flowとgithub-flowについて整理しつつ、違いについて解説するテクノロジーチーム開発実践入門を読み返しているのですが、その中に「git-flow」と「github-flow」がありました。見る既に多くのエンジニアが、Gitを使って開発しているかと思いますが、私も主に「git-flow」をベースに開発しています。読み返してみると「github-flow」は衝撃的なので、整理しつつ解説していきたいと思います。git-flow私の予想では、git-flowは多くの企業で使われているのではないかと予想しています。ブランチの登場人物こそ多いのですが、一度理解してしまえば難しくはありません。メインブランチメインブランチは、常に存在するブランチです。(メインブランチ)master本番環境のブランチです。masterブランチにマージされたコードは、本番環境へとリリースされます。重要な事は、常に本番環境と同一の状態を維持する必要があるということです。これによって、いつでも本番環境を再現できる環境が整います。(メインブランチ)develop開発用のブランチです。開発が完成した機能および修正から、developブランチへとマージされていきます。ある程度の修正が溜まった段階(例えば、スクラムであればスプリントの終わり)で、リリース準備を経てmasterブランチへとリリース(マージ)されていきます。サポートブランチ開発中や対応中の間だけ存在し、役目を終えたら消えていくブランチです。(サポートブランチ)featuredevelopから派生し、機能の追加や、優先度の低いバグ修正などの度に発生するブランチです。GitHubをご利用であれば、特定のissueを対応するために、issue毎にブランチとして切られたりします。機能の開発が完了し、developブランチにマージされたら、役目を終えて消えていきます。developブランチにマージをする際に、きちんとマージリクエスト(プルリクエスト)を発行していれば、記録としては残ります。ブランチは消えても、何を変えたのかはプルリクエストを見れば分かるのです。(サポートブランチ)releasedevelopから派生をし、リリース準備をするためのブランチです。releaseブランチは、masterへのリリースが終われば消えることもあれば、検証環境に対応したブランチとして、常に残しておく場合もあります。(サポートブランチ)hotfix緊急的なバグ修正などのために、masterから派生するブランチです。masterから派生し、直接masterへとマージされます。master」の流れでリリースされるのですが、緊急的なトラブル対応では時間的な余裕がありません。緊急時のトラブル対応として切られるのが、hotfixブランチなのです。github-flow以上が「git-flow」の解説なのですが、それに対して「github-flow」は、あまりにシンプルすぎて読んでいて笑っちゃいました。Requestがレビューされたらmasterにマージし、その場で本番環境にリリースする引用:チーム開発実践入門これだけなんですってよ奥さん!要は、常にリリース可能なコードを生み出していて、その場で本番環境へとリリースするのがgithub-flowなのです。過去に書いた「esa.ioの育て方」の記事で「30分後には修正版をリリースすることを目指す」という話がありましたが、正にこれを実践しているのがGitHubという企業です。このすみろぐさいごに「github-flow」の究極のスピード感を実現するためには、CI(継続的インテグレーション)やCD(継続的デリバリー)の環境整備に加えて、しっかりしたプルリクエストのレビュー体制の構築が必要不可欠です。普段何気なく使っているGitHubの裏で、一日に何十回もリリースが行われているとは思いませんでした。GitHub恐るべし。Native」を使っています。はてなブログProWEB系エンジニア。ブログで趣味の映画・ゲーム・読書の感想を書いたり、技術系の知見を共有しています。技術書典7にサークル参加して、技術同人誌を頒布しました。BOOTHに電子版があります。(1)月別アーカイブスポンサーリンクスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。