GitHub Flowを実際に試してみる

バージョン管理(Git/Github)
この記事は約8分で読めます。
スポンサーリンク

Git&GitHubでバージョン管理をやっていて、GitHubからクローンやプル、変更した内容をコミット、プッシュするなどはだいぶ理解できるようになってきました。

ただ、まだ理解が不十分なところがあります。主な疑問点は

  • 実際に開発を行う時にはどのような運用を行えばよいのか?
  • プルリクエストという言葉がよく出てくるがイメージがわかない。

今回はそんな疑問を解消すべく、一番シンプルでよく採用されているGitHub Flowというワークフローで実際の開発の流れを理解してみたいと思います。 また、GitHub Flowの一番の売りである機能のプルリクエストが理解できればブランチ運用についてかなり理解できると思います。

ブランチ運用

GitやGitHubでバージョン管理を行うときに、バージョン管理の方法や運用ルールは別に決められていません。 正直好きにやればいいのですが、複数人で開発を行うときなどには各個人で好き勝手なルールでバージョン管理をされると困ります。

そこで、開発の内容や規模、人数などによってこういうルールの元運用するとスムーズにできましたよという 成功例として挙げているのがワークフローです。

絶対にこの通りにやらないといけないわけではなく一つの指針となるフローです。

有名なワークフロー

Git-Flow

Git-Flowは役割ごとにブランチを分けて開発を進めていくブランチ運用 いくつものプロジェクトが並行して進んでいたり大人数で大規模な開発を進められる フロー。ブランチを切る数が多くフローが複雑というデメリットもあります。 ※ブランチ運用初心者にとっては難しい

GitLab-Flow

GitLabで使われているワークフローでGit-Flowを少し簡易的にしたイメージ ブランチを切る数もGit-Flowより少ないがそれでも少し複雑

GitFeatureFlow

ぐるなびのエンジニアの方が新しく提唱したブランチ運用。ブランチを切る数も少なくシンプル。 案件(Feature)ごとにブランチを切るブランチ運用

GitHub-Flow(今回はこれを試す)

一番シンプルでわかりやすい。プルリクエストを使うのが特徴

今回は一番シンプルでわかりやすく、プルリクエストを使うGitHub-Flowでやってみたいと思います。

GitHub-Flowの流れ

GitHubーFlowの流れを図で表すと以下のようになります。

前提条件

  • 開発用パソコンはWindows10
  • 開発用パソコンにGit For Windowsがインストールされていること
  • 開発用パソコンにTortoiseGitがインストールされていること
  • GitHubにユーザー登録されていること

インストールがまだの人は以下の記事を参考にしてください。
https://kajiblo.com/svn-git-ikou/

事前準備とリポジトリの内容

今回はテスト用でgithub-flow-testというプライベートリポジトリGithub上に作成しています。 今回はREADMEファイルを修正してmasterブランチに反映させるまでの手順を紹介しようと思います。

Add a README fileにチェックを入れるとREADME.mdというマークダウンファイルが作成される。

メイン画面のcodehttpsで表示される以下のURLがGitHubに作成したリポジトリのURL

①クローン/プル(開発用PC)

まず最初に開発用パソコンにGitHubのリポジトリをクローン。 開発用パソコンにローカルリポジトリがない場合はクローン すでに対象のリポジトリが開発用パソコンにある場合はプル

開発用パソコンにログインし、ソースを管理したいフォルダを作成します。

今回はCドライブに[github-test]というフォルダを新規作成。

作成したフォルダ内で右クリック→Gitクローン(複製)を選択

OKボタンを押すとgithub上に登録したファイルがクローンされる。

.gitというフォルダとREADME.mdというファイルがクローンされている

②ブランチを切る・チェックアウト(開発用PC)

このままREADMEファイルを修正するとmainブランチを修正してしまうのでまずは修正するために変更用のブランチを切る。

ブランチ名を指定する。(任意の名前でOK) ブランチはmain以外であれば何でもよいがブランチ名だけでいつどんな機能を追加したかがわかるような 名前を付けるとよい

OKボタンを押すとブランチが作成される また、ブランチが作成されると同時にgit.exe checkoutというコマンドが自動で実行され 作成したブランチに自動的に切り替わる。

③修正(開発用PC)

修正用のブランチに切り替わったのでファイルを修正する。
ブランチが切り替わっていることは右クリックでGitコミット->ブランチ名が変わっていればOK。
※今回の場合はyyyymm_xx機能追加となっていればOK

修正するファイル(README.md)を開いて修正。
以下の文言を追記して保存する

保存するとREADME.mdファイルが修正したことを表す赤のビックリマークが表示される

④コミット(開発用PC)

対象ファイルまたは対象フォルダを右クリックでコミットする。
※ブランチはmainではなくyyyymm_xx機能追加ブランチ

メッセージを入力してコミットボタンを押す
※TortoiseGitはメッセージを入力しないとコミットボタンが押せない

⑤プッシュ(開発用PC)

次に再度フォルダを右クリックTortoiseGit→プッシュを選択する。
この操作で開発用パソコンでつくったyyyymm_xx機能追加ブランチをGitHub上にアップロードしています。

ポイントはこの段階ではmainブランチはまだ何も変更内容が反映されておらずyyyymm_xx機能追加ブランチのみに 変更が反映されている点です。

Refで指定したローカルブランチyyyymm_xx機能追加ブランチを宛先originにプッシュする設定

URLで指定したGitHubリポジトリのURLにプッシュする

⑥プルリクエスト(GitHub)

⑤までの手順完了後にGitHubにログインすると以下のようにCompare & pull requestというメッセージが表示される。 また、開発用パソコンで作成したブランチも作成されbranchesの数が2つになる。

プルリクエストは修正内容をmainブランチに反映させる前に第3者が変更内容をレビューする機能。

承認の設定を行うと承認なしとマージできないようにする設定などもできる。

以下の内容を確認してCreate pull requestをクリックする。
プルリクエスト申請時にコメントを入力が可能。また、変更箇所が一目でわかるように表示してくれるので第3者もレビューしやすい。

⑦マージ(GitHub)

⑥でプルリクエストを作成するとPull requestタブに申請が上がったことが表示される。

以下の画面でMerge pull requestボタンを押す

ここでのマージはyyyymm_機能追加ブランチをmainブランチに反映する作業
Confilm mergeボタンを押すとマージされる。

⑧リモート作業用ブランチ削除(GitHub)

マージが完了するとメインブランチに変更内容が反映される。

今回追加した文言「github-flowテストでxx機能を追加」の文言が追加されている。

mainブランチに反映されたので変更用でブランチを切ったyyyymm_xx機能追加ブランチ削除する。
以下のbranchesタブをクリック

マージが完了していることを確認して削除

⑨ローカル作業用ブランチ削除(開発用PC)

最後に開発用PCに切っていたブランチを削除。

TortoiseGitであれば右クリック→TortoiseGit→refブラウザを開いて行う

削除したいブランチを選択して右クリック→ブランチを削除

以上が一連の流れです。

GitHub Flowの6つのルール

上述の流れはGitHub Flowが守るべき6つのルールを当てはめた運用となっています。
GitHub Flowでブランチ運用で守るルールは以下の6つです。

  • mainブランチは常にデプロイが可能な状態であること
  • 作業用ブランチは必ずmainブランチから作成する
  • 作業用ブランチ(開発用PC)は定期的にプッシュする
  • プルリクエストを使う
  • プルリクエストが承認されたらmainブランチにマージする
  • mainブランチへ反映したらすぎにデプロイする

これら6つのルールが守れない状況が発生する場合は他のフローを検討する必要があると思います。 個人的にはmainブランチに反映したらすぐにデプロイするというところが業務の都合上難しかったりします。 GitHubフローはあくまで一つの例なので業務に合わせてフローを変更するのも一つの手だと思います。

GitFeature FlowもぐるなびのエンジニアさんがGitHub Flowを応用して急なリリースやリリース日変更にも対応できるフローを提唱したものだったと思います。

GitFlowは使わない!シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ
こんにちは!テニスはじめました、小山です。開発部門でウエディンググループのリーダーをやっています。 今回は私が考えた新しいGitのブランチモデル「GitFeatureFlow」についてお伝えしたいと思います。

コメント

タイトルとURLをコピーしました