はじめに

【GitHub】ブランチの運用方法についてで
GitHub Flowについて軽く紹介していますので、ぜひそちらもご覧ください。

この記事は独学で学習中の筆者がGitHub Flowについて学習してみて、
一連の操作（またはコマンド）を紹介している記事になります。
ツッコミどことがあるかもしれませんがその際は教えていただけますと幸いです。

この記事は、GitHubは使ったことがあるが
しっかりとした運用方法で使ったことはないという方におすすめだと思います。

GitHub Flow

GitHub Flowは、ブランチの有名な運用方法の中の一つです。

ブランチとは、履歴の流れを分岐して記録していくためのものです。
分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。

また、分岐したブランチは合流させることもでき、それをマージと言います。

GitHubではリポジトリ作成時にmasterというブランチが自動作成されるのですが、
GitHub Flowではmasterブランチを常時デプロイが可能であるブランチとします。

常時デプロイが可能であるとはどのような状態かというと、
常に安定しているブランチで、リリース可能な状態であるということということです。

機能の追加やバグ修正を行いたい場合にmasterブランチをいじってしまうと、
「常時デプロイが可能である」というルールを破ってしまうことになるので、
作業用のブランチを作成してそちらで作業をおこないます。

作業終了後にmasterブランチにマージしデプロイするという流れです。

次にGitHub Flowのルールですが、下記のようなルールがあります。
(全人類共通かわかりませんが私の認識ではこんな感じです。)

1. masterブランチは、常時デプロイ可能な状態を保つ
2. 全てのブランチはmasterブランチから作成する
3. 作業内容が分かるようなブランチ名をつける
4. 作業中のブランチは定期的にプッシュする
5. Githubのプルリクエストを利用してレビューを行なってから、masterブランチにマージする
6. マージされたmasterブランチのコードはすぐにデプロイする
7. デプロイ後は速やかに作業していたブランチを削除する

文章だけだとわかりにくいと思いますので、実際に運用してみようと思います。

運用手順

まずはじめに、リポジトリを作成します。
自分のGitHubのページから右上の＋をクリックし、New repositoryを選択します。

リポジトリ作成画面に来たら、リポジトリの名前を入力し、Create repositoryをクリックします。

今回は練習なのでAdd a README fileにチェックは付けていません。

READMEファイルとは、説明書的なものなので必要な方は付けてください！

作成すると次のような画面になると思いますので、
四角で囲んでいる箇所をSSHにし、右に記載されているgit@から始まるURLをコピーしておいてください。

次にターミナルを起動します。
command + スペースキーで検索フィールドを出しターミナルと入力しEnterを押します。

ターミナルが開かれるわけですが、ここから少し操作していきます。
今回はデスクトップ上にtestディレクトリを作成し、そちらにcloneを作成します。

下のコマンドを順に打っていけば作業を進められますが、
なんとなくでいいので理解しながら進めた方がいいかもしれません。

ディレクトリ作成

$ mkdir test   

作成したディレクトリに移動

$ cd test/   

作成したリポジトリのcloneを作成(######は人によって異なります)

$ git clone [email protected]:######/github-flow.git

クローンで複製したgithub-flowに移動

$ cd github-flow/   

sampleFileを作成します

$ touch sampleFile    

sampleFileを編集し適当にテキストを入力
viでの編集がよくわからない方は、普通にデスクトップから操作してファイルを作成してください。

内容はなんでもいいですが、私はtest1にしました。

$ vi sampleFile    

作成したファイルをaddする
addすることにより、バージョン管理の対象としてsampleFileを追加することができます。

$ git add sampleFile    

gitの状態を確認してみます。
一番下のnew file: sampleFileから
先ほど作成したファイルがステージ領域（コミット前の一時領域）に追加されていることがわかります。

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   sampleFile

コミットの実施
git commitだけでもコミットすることはできますが、コメント画面などを省略するために下記のように実施しました。

git commit -m "1回目のコミットです。"

ログの確認
ログを確認するとコミットされていることがわかります。

$ git log
commit f4e4a23f609481a8a1f4a2bbf21b9f121684 (HEAD -> master)
Author: Onishi Ryosuke <[email protected]>
Date:   Sat Feb 20 12:41:39 2021 +0900

    1回目のコミットです。

リモートリポジトリへ送信
コミットした内容を送信します。

$ git push
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 261 bytes | 261.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:onishi-app/github-flow.git
 * [new branch]      master -> master

最初に作成したリポジトリの画面にいきページの更新をおこないます。
すると次のような画面になっていると思います。

sampleFileがgithub-flowリポジトリに存在しており、
コミットの時のコメントが振られています。

sampleFileをクリックすると画面が移動し、
sampleFileの中身の内容を表示してくれます。

では、今のmasterブランチの状態がデプロイ可能な状態であると仮定してGitHub Flowの運用を行っていきたいと思います。
現在のmasterブランチにはsampleFileが作成されており中身にはtest1と記載されている状態です。

今回は、「sampleFileにtest2という文字を追記する」という作業を行う流れをGitHub Flowで行っていきます。

おさらいですが、GitHub Flowのルールは下記のような内容です。

1. masterブランチは、常時デプロイ可能な状態を保つ
2. 全てのブランチはmasterブランチから作成する
3. 作業内容が分かるようなブランチ名をつける
4. 作業中のブランチは定期的にプッシュする
5. Githubのプルリクエストを利用してレビューを行なってから、masterブランチにマージする
6. マージされたmasterブランチのコードはすぐにデプロイする
7. デプロイ後は速やかに作業していたブランチを削除する

1. masterブランチは、常時デプロイ可能な状態を保つに関しては
現在のsampleFileがデプロイ可能な状態であると仮定して進めていきます。

ブランチの作成

次に、2. 全てのブランチはmasterブランチから作成するをおこないます。

ターミナルの場合

ブランチの作成
git branch <branch名>

今回は、feature-add-test2という名前のブランチを作成しました。
※masterブランチから実施しないとmasterブランチからの分岐になりません。

$ git branch feature-add-test2

ブランチが作成されているか確認

現在存在するブランチの一覧が表示されます。
現在は、masterブランチと先ほど作成したブランチが表示されるはずです。

また、*がついている方が現在操作しているブランチになります。

$ git branch
  feature-add-test2
* master

ブラウザの場合

赤枠のmasterをクリックします。

検索フィールドが表示されますが、ここに作成したいブランチの名前を入力します。
ブランチが存在しない場合はCreate branch:ブランチ名 from "master"と表示されますので、
そこをクリックするとmasterブランチから分岐したブランチを作成することができます。

ここまででブランチが作成できたと思います。

作業ブランチの変更

では、次にブランチの移動を行いたいと思います。

現在いるブランチはmasterだと思います。
masterブランチは常にデプロイ可能な状態である必要があるので
masterブランチのファイルを編集してしまうと編集中はデプロイが可能な状態ではなくなってしまいます。

なので、masterブランチと同じ状態であるfeature-add-test2ブランチを修正し修正内容をmasterブランチにマージします。

ターミナルの場合

先ほど作成したブランチに移動するためにcheckoutコマンドを使用します。

$ git checkout feature-add-test2

ブラウザの場合

リモートリポジトリの最新の状態をローカルリポジトリに取得します。

リモートリポジトリ
-> 「リモートにある」つまり元となるリポジトリになります。

ローカルリポジトリ
-> 「ローカルにある」つまり自分の手元（PC）にあるリモートリポジトリから複製したリポジトリになります。

$ git pull
From github.com:onishi-app/github-flow
 * [new branch]      feature-add-test2 -> origin/feature-add-test2
Already up to date.

これでリモートリポジトリの状態を取得することができました。

では、ブランチの確認をしてみます。
-aをつけることにより、ローカルリポジトリだけでなくリモートリポジトリも含んだブランチ情報を取得できます。

remote/origin/~のブランチはリモートリポジトリのブランチになります。

$ git branch -a
* master
  remotes/origin/feature-add-test2
  remotes/origin/master

リモートリポジトリのfeature-add-test2をローカルリポジトリに持ってきたいのでcheckoutします。

コマンドは次のようになります。
git checkout -b <ローカルに作成するブランチ名> <checkout元のブランチ名>

$ git checkout -b feature-add-test2 origin/feature-add-test2
Branch 'feature-add-test2' set up to track remote branch 'feature-add-test2' from 'origin'.
Switched to a new branch 'feature-add-test2'

再度ブランチ情報を確認するとリモートリポジトリの内容をローカルに持ってきつつ、
作業ブランチも移動していることが確認できます。

$ git branch -a
* feature-add-test2
  master
  remotes/origin/feature-add-test2
  remotes/origin/master

修正作業の実施

4. 作業中のブランチは定期的にプッシュするに関しては定期的にpushを行うことようにしてください。
test2という文字を追加するだけでは一度のpushで済んでしまいますので、
「test2」と「テスト２」を2回に分けて追加してみます。

では、最初にsampleFileにtest1という文字を記述した流れと同じ感じでtest2も追記してみます。
※現在のブランチがfeature-add-test2であることを確認してから行ってください。

ちなみに追加後は下記のような状態になりました。

$ cat sampleFile 
test1
test2

では、修正が行えたのでpushしたいと思います。

$ git add sampleFile    // addしてます

$ git commit -m "add test2"    // commitしてます
[feature-add-test2 9c7a38c] add test2
 1 file changed, 1 insertion(+)

$ git push    // pushしてます
Enter passphrase for key '/Users/ryosuke/.ssh/id_rsa': 
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 263 bytes | 263.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:onishi-app/github-flow.git
   f4e4a23..9c7a38c  feature-add-test2 -> feature-add-test2

ここまでの状態を確認してみます。

ターミナルの場合

masterブランチに移動します。

$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

sampleFileの内容を確認します。
先ほど記載したtest2がmasterブランチには反映していないことが確認できます。

$ cat sampleFile 
test1

feature-add-test2ブランチに移動します。

$ git checkout feature-add-test2
Switched to branch 'feature-add-test2'
Your branch is up to date with 'origin/feature-add-test2'.

feature-add-test2ブランチのsampleFileは修正されていることが確認できます。

$ cat sampleFile 
test1
test2

ブラウザの場合

masterブランチには1回目の状態が記載されています。
（1回目のコミットですと表示されています。）

次に、feature-add-test2ブランチを確認したいので、
masterをクリックし、feature-add-test2を選択してください。

するとこちらは先ほどpushした内容が反映されていることがわかります。

確認後、テスト２という文字を追記して同じことをおこないます。
追加や確認などの手順は省略しますが、確認したい方は先ほどの手順で確認してみてください。

Pull Requestとマージ

次に5. Githubのプルリクエストを利用してレビューを行なってから、masterブランチにマージするを行います。

先ほどブランチを分けて修正を行いました。
全ての実装が完了しデプロイできる状態だ！となりましたら次はmasterブランチにマージすることになります。

ですが、ただマージするだけでは安全性が低いので、
上司などの上の立場の方に修正点をチェックしてもらう必要があります。

そこで使える便利な機能がPull Requestです。
Pull Requestを行うことにより、リポジトリの管理者（上司の方々）が修正内容を確認し
問題がなければマージを行ってもらうことができます。

Pull Requestのやり方は、下記のような流れになります。
① リモートリポジトリのクローンをローカルに作成 -> 実施済み
② ローカルリポジトリで作業用のブランチを作成 -> 実施済み
③ 作業用ブランチの内容をリモートリポジトリにpushする -> 実施済み
④ ブラウザからPull Requestの作成 -> これから実施

作業用ブランチを作らないでmasterで修正を行ってpushをしても
Pull Requestを行うことができませんので注意してください。

では、ブラウザからPull Requestを作成します。

今までの作業を実施すると、ブラウザには赤枠の内容が表示されているはずです。
Compare & Pull Requestをクリックします。

コメント欄には適当にそれっぽいことを記入しておきます。
本来でしたら作業内容などを記入するのかと思います。

記入後にCreate pull requestをクリックします。

masterブランチを表示しPull requestをクリックすると、
先ほど作成した作業用ブランチの名前でリクエストされています。

このリクエストをクリックすると次の画面に移動します。

管理者はこのPull Requestの内容を確認してマージするかどうか判断します。

赤枠の部分が各コミットの内容になります。
「テスト２を追加しました」をクリックしてみると次の画面に移動します。

この画面ではこのコミット時の変更内容が分かりやすく表示されております。

先頭に＋と記載されている箇所が追加した箇所です。
ここの修正に指摘したい場合は修正箇所にカーソルを合わせると青色の＋ボタンが表示されますでのクリックします。

すると下にテキストフィールドが表示されるので指摘内容を記載します。
その後右上のFinish your Reviewをクリックするとレビュー完了です。

開発者は管理者からのレビューを修正し再度Pull Requestを送信します。
最終的に指摘がなくなってマージしてもいい状態まで仕上げます。

マージする場合はMerge pull requestをクリックします。

次にConfirm mergeをクリックします。

masterブランチの内容を確認するとfeature-add-test2の修正内容が反映されていることがわかります。

ブランチの削除する

最後に7. デプロイ後は速やかに作業していたブランチを削除するを実施します。
作業が終了し必要なくなったブランチをいつまでもとっとく理由はないので削除の一択ですね。

branchesをクリックします。

いらないブランチのゴミ箱ボタンをクリックします。

branchesの数がmasterのみとなっていることが確認できればブランチの削除は完了です。

ここまでで一連の流れは終了です。

さいごに

どうでしょうか。私の説明で理解できた方がいらっしゃったら嬉しいですが・・・。
このような運用をすることにより、安全かつ迅速にサービスのアップデートを行うことができます。

GitHub Flowだけでなく他にもさまざまな運用方法があるので
ぜひ自分に合うものを見つけてみてください！

かなり長くなってしまいましたが最後まで読んで下さってありがとうございました。