※ 本講座は、動画コンテンツが未作成です。

はじめに

前回のレッスンでは、GitHub の初期設定を行い、リポジトリをローカルに落としてきました。

今回は、GitHub での開発のフローについて学んでいくのですが、まずはじめに、流れのイメージを掴んでもらうために図にしました。

この図を見ていただくとわかると思いますが、また新しい Git コマンドが出てきます。今回のコマンドは、リモートリポジトリとデータをやり取りするコマンドです。

流れがつかめれば、そこまで難しいことはありません。それではやっていきましょう。

GitHub での開発の一連の流れ

まずは、図と照らし合わせながら、どういった流れで開発が行われるかを見ていきます。図に振っている番号をもう少し詳しくすると以下のようになります。

GitHubでの開発の一連の流れ
  1. 対象のリポジトリをローカルにクローンする
  2. ローカルでファイルを編集し、新しいブランチを生やしてコミットを出す
  3. ローカルのブランチをリモートリポジトリにプッシュする
  4. GitHub 上で「プルリクエスト(Pull Request)」を出す
  5. (必要であれば)共同開発者にレビューをしてもらう
  6. レビューが通ったら、GitHub 上でマージする
  7. リモートリポジトリの情報をローカルリポジトリに反映させる

実際に手を動かしながら、それぞれの操作について確認していきましょう。

 

GitHubを使った開発フロー詳細

1. 対象のリポジトリをローカルにクローンする

こちらは、前回のレッスンで既に済んでいますね。

$ cd ~/git/training-git
$ code .

で、クローンしたリポジトリに移動して、エディターを開いておきましょう。

2. ローカルでファイルを編集し、新しいブランチを生やしてコミットを出す

今回は練習なので、適当にファイルを編集して新しいブランチにコミットを出します。

Readme.md ファイルの作成

まだ何もファイルがないと思うので、Readme.md というファイルを作りましょう。

このファイルは、GitHub 上のリポジトリのトップページで表示されるファイルです。

md の拡張子は、マークダウン と呼ばれる書き方で記述のできるものです。

マークダウンはプログラマーが好んで使う記法なので、基本的な書き方は覚えておいたほうがいいのは確かなのですが、今回の本題からずれるので割愛します。

以下のリンクに GitHub のマークダウン記法がまとまっていますので、参考に貼っておきます。

話を戻して、以下のようにファイルを作成・編集し、保存してください。

新しいブランチに commit する

まずは今のブランチを確認。

$ git branch

* master

master ブランチになっていると思います。

前回のレッスンの一文を引用します。

これは、git init でローカルリポジトリを作成した後、初めてコミットをすると自動的に作成されるのが master という名前のブランチだからです。

GitHub 上でリポジトリを作成したタイミングで、 .gitignore ファイルを作るような設定にしていたため、自動的に master ブランチが作られたために master ブランチが選択された状態になっているわけです。

この master ブランチから新しいブランチを作り、そのブランチにコミットを投げます。

$ git switch -c create-readme
$ git add Readme.md
$ git commit -m "Create Reame.md"
$ git log

commit 2d244ef66395f7b35a2f90cb070922bb81142f3a (HEAD -> create-readme)
Author: take-off-rails <45061808+take-off-rails@users.noreply.github.com>
Date: Sun Nov 25 21:40:42 2018 +0900

Create Reame.md

commit c3b876ebffa67c9dfcec850e5d2e1e0532e98f58 (origin/master, origin/HEAD, master)
Author: take-off-rails <45061808+take-off-rails@users.noreply.github.com>
Date: Sun Nov 25 21:26:33 2018 +0900

Initial commit

これで、Readme.md の編集を commit できました。

3. ローカルのブランチをリモートリポジトリにプッシュする

次は、今の編集をリモートリポジトリに反映させます。

コマンド操作の場合

方法は簡単で、git push コマンドを実行します。

実際は、以下のコマンドです。

$ git push origin HEAD

自動的に作成されるリポジトリの名前が origin で、 HEAD はコミットの一番新しいものを指します。

なので、上記コマンドは、

珍獣
GitHub で作成されたリポジトリ(origin)に、ローカルリポジトリの一番新しい commit までを反映させてね!

 

という意味のコマンドになります。

※ push するたびに、上のコマンドを打つのは若干面倒なので、もう少しあとのレッスンで、ショートカットコマンドを打てるようにします。

実際に実行して以下のようになれば OK です。

$ git push origin HEAD
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 294 bytes | 294.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'create-readme' on GitHub by visiting:
remote: https://github.com/take-off-rails/training-git/pull/new/create-readme
remote:
To https://github.com/take-off-rails/training-git
* [new branch] HEAD -> create-readme

ここまでで、③の操作まで完了しました。

SourceTree の場合

  1. ファイルを編集
  2. commit
  3. push

の流れを SourceTree でもやってみましょう。

まずは追加で Readme.md を修正します。

SourceTree を開いて commit しましょう。

最後に、ブランチ名を右クリックして出てくるメニューからプッシュ先を選択します。

すると、対象のブランチがチェックされた状態で表示されるので、OK してください。これで push が完了です。

※ 以降の解説では、ここでの SourceTree の追加 push はしていない前提で解説しています。ご了承ください。

4. GitHub 上で「プルリクエスト(Pull Request)」を出す

さて、ローカルマシンの操作から一旦離れて、次は GitHub で Pull Request を出していきます。出す前に、まずは Pull Request とは何か から説明しますね。

Pull Request とは

あるブランチAから、別のブランチBに対して変更をリクエストします。

このリクエストのことをプルリクエスト(Pull Request)と言います。

「プルリク」「PR」と略されることが多いです。

以下の図を見てください。先ほど作成した create-readme ブランチを master ブランチに向けて「プルリクエスト」を出している図です。

一番初めに出した図の ④〜⑥ の操作の詳細を図にするとこのようになります。

これから実際に、この流れを GitHub 上で作っていきます。

Pull Request を出す

それでは GitHub 上の画面に移ってください。

まず、以下の①の Pull Requests ボタンを押すと画面がこの画像のようになると思います。

次に ②の New pull request ボタンを押しましょう。

すると、Compare changes の画面になります。

base で master が選択されていますが、これが、先ほどの図で言うところの ブランチ B です。

今回は ブランチAcreate-readme にする必要があるので、クリックしてセレクトボックスから比較したいブランチを選択しましょう。

すると、差分が表示されます。

選択したブランチが間違っていないことを確認し、緑色の Create pull request ボタンをクリックします。

次の画面では、この Pull Request がどのような変更を加えるものなのかを書くテキストボックスが表示されます。以下のようなものです。

タイトルの部分に、この変更がどんな内容のものなのかを端的に。

本文には、この変更についての詳しい情報を書きます。本文は、マークダウンで書くことができるので、試しに以下のように書いてみてください。情報を追記したら、右下の緑井のボタン「Create pull request」を押します。

これで、Pull Request を出すことができました!

5. (必要であれば)共同開発者にレビューをしてもらう

一人での開発では特にないフローなのですが、チーム開発では基本的に出した Pull Request を GitHub 上でレビューし合うのが一般的です。

今回はひとりで開発しているので、レビューはありませんが、軽くどこをチェックすればいいかだけ確認しておきましょう。

ファイルの差分を確認する

対象のプルリクエストを開くと、Files Changed タブがありますので、そこをクリックします。すると、この Pull Request で変更された差分を一覧で確認することができます。

この差分をざっと見て、変更点に問題がないかをチェックします。

この Files Changed タブで変更点が問題なさそうかは確認するようにしておくと、ちょっとしたミスに気づける ので、ざっとみるのを習慣にしておくのをおすすめします。

6. レビューが通ったら、GitHub 上でマージする

一旦、レビューが通ったと仮定して次に進めましょう。

Files Changed タブから、 Conversation タブに切り替えます。

すると、下の方に Merge pull request ボタンが表示されますので、このボタンをクリック。

表示が変わって、このマージのコメントを書くテキストボックスが表示されます。

Merge コメントは、 git log で確認できるコメントなので、この Pull Request でどのような変更を加えたのかを書くとよいです。

割とここは変更せずに、そのままマージする運用をしているところも多いので、このままマージしてしまいましょう。

Confirm merge ボタンをクリックします。

すると表示が変わり、 Pull request successfully merged and closed と表示されましたね。マージが成功し、プルリクが自動的にアクティブではなくなります。

 

マージした後は、基本的にもうブランチは使わないので、右の Delete branch ボタンを押してブランチを消す癖をつけておきましょう。

癖にしておかないと GitHub 上に使っていないブランチがずっと残ってしまって、どれが使用中のブランチなのかわからなくなりがちです。

プルリクが出ている状態では、上の Pull Request ボタンを押すと一覧に表示されていたのが、マージされると自動的にアクティブではなくるため、一覧から消えます。

これで、無事にリモートリポジトリの master ブランチに、修正した情報が反映されました。

Code タブをクリックすると、以下のように Readme.md が反映されていることがわかります。

7. リモートリポジトリの情報をローカルリポジトリに反映させる

最後に、この GitHub のリポジトリをローカルに反映させましょう。

いつものように、まずはイメージ。

図にあるように、情報を取得するためのコマンドは2つあるので、それぞれの違いについて把握しておきましょう。

先ほど、GitHub 上の master ブランチに変更がマージされたので、その情報をローカルにも反映させたいわけですが、リモートから情報を取得するコマンドは主に2つ準備されています。それぞれの違いを把握していきましょう。

git fetch

git fetch は、リモートリポジトリの情報を取得するコマンドです。

このコマンドは、ローカルのブランチには特に影響を与えません。単にリモートの情報を取得するだけのコマンドです。主に、リモートリポジトリのブランチと commit 履歴の2つを取得するコマンドと覚えておきましょう。

コマンド操作の場合
$ git fetch

めっちゃシンプルですが、これだけでリモートの情報を取得できます。他の誰かがコードを書いて push したあとに、その情報を取得したい場合は fetch を使います。

SourceTree の場合

すでにローカルとリモートの状態が同じではありますが、操作を一通り行ってみましょう。

fetch はすごくシンプルで、フェッチボタンを押して OK するだけです。

git pull

git pull は、現在選択しているブランチの情報を取得(git fetch)し、マージ(git merge)するコマンドです。

git pull のコマンドは、「どのブランチの情報を取得してローカルのブランチに反映するか」を指定するため、データの取得も特定のブランチだけになります。

コード操作の場合
$ cd ~/git/training-git
$ git checkout master
$ git pull origin HEAD

remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
From https://github.com/take-off-rails/training-git
* branch HEAD -> FETCH_HEAD
Updating c3b876e..c7bd628
Fast-forward
Readme.md | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 Readme.md

この場合、リモートの master ブランチの情報を取得し、ローカルの master ブランチに変更を反映します。

git log を確認すると、GitHub 上のマージが正常に反映されていることがわかります。

$ git log

commit c7bd628e1b8b7dfe8eb09d68729c87c718c54df9 (HEAD -> master)
Merge: c3b876e a652cd2
Author: take-off-rails <45061808+take-off-rails@users.noreply.github.com>
Date: Mon Nov 26 00:32:41 2018 +0900

Merge pull request #1 from take-off-rails/create-readme

Create Reame.md

このように、基本的にリモートの情報をローカルに反映させる場合は git pull を使います。

SourceTree の場合

現在選択中のブランチの情報を pull する方法ですが、これもシンプルで プルボタンを押すだけです。

今は master ブランチを選択中なので、「プルするリモートのブランチ」も master になっています。あとは OK を押すだけです。

他に、リモートにしか存在しないブランチを pull したい 場合があると思います。そんなときは、リモートからブランチを選択して pull すれば OK です。

「チェックアウト」をクリック

もし、GitHub にはブランチが存在するのに、リモートの一覧に pull したいブランチがない場合は、git fetch を先にしてあげれば OK です。

 

これで、「リモートリポジトリの情報をローカルリポジトリに反映させる」ことができました!

以上の話を踏まえて、もう一度図を見てみましょう。

 

まとめ

今回は結構な大ボリュームでしたが、お疲れ様でした!

最後に復習のために、はじめの図を確認してみましょう。

GitHubでの開発の一連の流れ
  1. 対象のリポジトリをローカルにクローンする
  2. ローカルでファイルを編集し、新しいブランチを生やしてコミットを出す
  3. ローカルのブランチをリモートリポジトリにプッシュする
  4. GitHub 上で「プルリクエスト(Pull Request)」を出す
  5. (必要であれば)共同開発者にレビューをしてもらう
  6. レビューが通ったら、GitHub 上でマージする
  7. リモートリポジトリの情報をローカルリポジトリに反映させる

それぞれの操作を思い出しながら確認してみてください。

もちろん、一度で全てを覚える必要はありません。この操作は、何度も繰り返すことになるので、一連の流れを忘れてしまったときに、このレッスンの内容を確認することを思い出せれば OK です!

それでは今回はこれで終わりになります。お疲れ様でした!

前の記事 / 次の記事