1. 事前準備

git-app というアプリケーションを作成し、作業を進めていく。

アプリケーションを新たに立ち上げる

git-app というアプリケーションを新たに作成

以下の手順で操作をしていく。

ターミナル

$  pwd  #現在のディレクトリがprojectsであることを確認
$  rails new git-app -d mysql
$  cd git-app
$  rails db:create

これでアプリケーションのベースは作成できた。

ローカルリポジトリを作成してコミットする

git-app をローカルリポジトリにする

以下の手順で作業していく。

GItHub Desktop から git-app のローカルリポジトリを作成。左上の「Current Repository」→「Add」→「Add Existing Repository」を選択

projects にある git-app を選択し「Add Repository」をクリック

「Add Repository」がクリックできない場合、以下の作業を行う。
該当するアプリケーションのディレクトリで以下の作業を行った後に、「ローカルリポジトリを作成」の作業を行う。

ターミナル

1 2	$ cd ~/projects/git-app $ git init

rails のバージョンによっては rails new 時に git init がされないケースがある。

コミットする

ローカルリポジトリにある全てのファイルを選択してコミットする。その際のコミットメッセージは、最初のコミットなので「Initial commit」としておく。

リモートリポジトリを作成

リモートリポジトリを作成する。今回はローカルリポジトリをプッシュする方法でリモートリポジトリを作成していく。

リモートリポジトリを作成

コミットしたので、リモートリポジトリに反映させる。
まだリモートリポジトリを作っていないが、GitHub Desktop では、Publish ボタンを押すとリモートリポジトリが作られていない場合にリモートリポジトリも作ってくれる。

すると、以下のようなモーダルが表示され、リモートリポジトリを作成できる。リポジトリ名はそのままで構わない。
リポジトリを非公開にする必要はないので、今回は[Keep this code private]のチェックは外しておく。

[Publish repository]ボタンをクリックすると GitHub のリモートリポジトリが作成できる。

ここで GitHub のトップページに移動する。
GitHub の Your repositories の欄に git-app があれば上手く行っている。

以上で事前準備は完了。

2. ブランチを作成する

ブランチについて

ブランチとは、リポジトリで管理しているプロジェクトの流れを記録していく場である。リポジトリは必ずブランチを持っている。これはリポジトリのバージョン管理がブランチの上で行われているためである。

Git でリポジトリを作成した時点で、開発者はmaster ブランチという履歴上で開発をする状態となる。そこからトピックブランチを作成し、機能別に並行作業していく。ブランチ（branch）は「枝」という意味。１つの主流から枝の様に別れてプロジェクトが管理できるとイメージ。

master ブランチ

master ブランチとは、リポジトリに最初のコミットを行うと自動で作成されるブランチ。master ブランチがリポジトリの大元のブランチとなることが多い。これまで行ってきたコミットはすべて master ブランチの履歴上で管理されていた。

トピックブランチ

ブランチは複数作ることが出来る。そして、ブランチを作るにはすでにあるブランチをコピーしなくてはいけない。最初のブランチは master ブランチなので、次に作るブランチは master ブランチをコピーしたブランチになり、それをトピックブランチと言う。

実際の開発では下図の様に、機能ごとにトピックブランチを作成して、完成したら master ブランチに結合していく。

ブランチを作成する

ブランチは実装機能ごとに作成すると良い。今回はアプリケーションのメイン機能である、記事を投稿する機能を実装する。

記事投稿機能についてのブランチを作成

以下から新しいブランチを作成できる。

master ブランチから新しいブランチを作成する。ブランチ名は記事の投稿機能を実装するブランチなので、add-posting-article-functionとする。

ブランチ作成後に、add-posting-article-functionブランチに切り替わっているか確認する。

上図の様になっていれば、新しいブランチを作成し、作業場をそのブランチへ移動出来ていることになる。

3. プルリクエストを作成

ブランチを用いた開発を行う上で、プルリクエストについても並行で学ぶ必要がある。

プルリクエストについて

機能実装のためにコードを追記したり、保守のために修正したりするときにブランチは作成される。そのため、そのコードは誰かにチェックをしてもらう必要がある。そこで役立つのがプルリクエスト。

プルリクエストとは

ブランチでのコミット履歴を残すと共に、各コミットにおける変更修正にコメントをつけることができる GitHub の機能のことを言う。以下の図のような形で、１つのブランチでの作業について、コミュニケーションが取れる掲示板のようなものがプルリクエスト。

プルリクエストを作成

プルリクエストの作成は以下の流れ。

空のコミットを作成する
プッシュする
プルリクエストを作成する
同じブランチで変更修正を加えていく

順番にこれらの作業を追っていく。

空のコミットを作成してプッシュ

プルリクエストを作成するには対象のブランチで少なくとも１つのコミットを新たにしなくてはならない。しかし、現状このブランチではまだ作業をしていないのでコミットできるものがない。

この場合、 空のコミット をすることでプルリクエストは作成できる。

ターミナル

1	$ git commit --allow-empty -m 'create pull request' # --allow-emptyオプションで何も作業が無くても（git statusで何も表示されていなくても）コミットできる

GitHub Desktop で add-posting-article-function ブランチで空のコミットができていることを確認。

[Publish branch] をクリックしてプッシュ。

プルリクエストを作成

まず、プッシュをしたら GitHub Desktop 上の [Create Pull Request] をクリック。

すると以下の画像のようにブラウザが起動して、プルリクエスト作成画面が表示される。以下のように情報を入力してプルリクエストを作成する。

プルリクエスト作成時のポイント

プルリクエストのタイトルには[WIP]をつける

WIP とは、Work In Progress の略で作業中の意味。反対に作業が終わっている場合には WIP を外します。「実装途中の機能には WIP をつける」「実装が一旦完了したプルリクエストからは WIP を外す」と考える。上記のアプリケーションではまだ投稿機能は実装途中であるため、この時点では WIP を付けておく。

プルリクエストの詳細には、What（何を）と Why（なぜ）を書く

What（どのような実装をしているのか）と Why（なぜこの実装が必要なのか）を書くことで、このブランチは何を実装していて、なぜその実装を行ったのかが他の人に伝えることができる。What をしっかり書くことで、他者にコードを見てもらう際に、スムーズな理解を促すことができる。アプリケーションの機能が複雑になればなるほど、コードを読んだだけでは、何をしているのか把握することは難しくなるからである。また、Why をしっかり書くことで、本来の目的に沿ったコミュニケーションが可能となる。実装目的が伝わっていないと、欲しい意見をもらうことはできない。
Pull Request に最初に書き込むメッセージは会社やチームによって異なる。

マークダウン表記で書くこと

マークダウンとは記法の一種。マークダウンを使うことでシンプルな記法で HTML 文書を書くことができる。

4. 作成したブランチで実装

add-posting-article-function ブランチで実際に投稿機能を作成する。今回は一から投稿機能を実装するのではなく、Rails が備えている scaffold というジェネレーターを使用する。scaffold を使えば、アプリケーションの雛形のソースコードを自動で生成してくれる。

scaffold でコードを生成

ターミナル

1	$ rails g scaffold article title:string author:string text:text

このコマンドによって article に関する、コントローラーやモデル、マイグレーションファイルなどが一括で生成された。生成されたマイグレーションファイルを実行する。

ターミナル

1	$ rails db:migrate

以上でアプリケーションの雛形が完成したのでサーバーを起動してlocalhost:3000/articlesに接続してみる。

作業内容をコミット・プッシュする

投稿機能を実装できたので、ここまでの作業内容をコミット、プッシュ。GitHub Desktop で全てのファイルを選択してコミットする。コミット名は「generated files by scaffold」にし、コミットができたら、プッシュする。

コミットを確認

ブラウザで先程作成したプルリクエストのページを確認すると、generated files by scaffoldのコミットが反映されている。

5. コードレビュー依頼をする

複数人での開発においては、コードの記述内容に問題が無いか、他の開発メンバー等にレビューを依頼する。それをコードレビューと言う。

コードレビューを依頼

投稿機能の作業が終わったので、次はレビューを依頼する。プルリクエストの URL（https://github.com/<ユーザー名>/git-app/pull/1のような形になっているはずです）を共有することで、他者にレビューを依頼することができる。

WIP を外す

レビューを行う前に WIP を外す。というのも、今回のプルリクエストでは投稿機能の実装が目的だったので、現時点で目的の機能実装は完了しているため、WIP を外す。以下のようにするとプルリクエストのタイトルを修正できる。

URL を確認

共有すべき URL の確認をしておく。以下の様になっているはず。

上記以外の URL（例えばリポジトリの URL）を共有しても、レビューする人はどのプルリクエストをレビューすべきなのかわからず、無駄な時間が発生してしまう。間違えないように注意。

コードレビュー依頼

レビュー依頼の方法は様々。Slack 等で URL 共有する方法もあれば、プルリクエスト上で Slack の様に username にメンションをつけることで本人にレビュー依頼の通知が行くようにすることもある。

（レビュアー側の場合）コードレビューをする

自分がレビュアーになった場合、プルリクエストにコメントする。

プルリクエストにコメント

Files changed をクリックすると、変更修正されたコードが一覧できる。

コードを見てみると、articles.coffee というファイルが生成されていた。今回の場合はこのファイルは必要ない。消すように指示を出す。

特定のファイルのコメントを残したい行にカーソルを当てると、青色の＋ボタンが現れる。このボタンを押すとコメント用のフィールドが現れるのでコメントを書く。以下のように記述して Add single comment をクリックする。

また、特定のファイルではなく、プルリクエスト全体に対してのコメントを残すこともできる。
今回は、プルリクエスト Conversation タブの最下部からプルリクエスト全体に対して、画像と同じようにコメントする。

指摘点を修正して、再度コードレビューを依頼

レビューを元にコードを修正していく。今回は例なので自身で書いたレビューを修正。レビューについてわからない点があればコメントに返信する形で質問することもできる。

コードを修正

今回のコメントの例では、いくつかのレビューをもらったが、指摘された箇所をまとめて修正してコミットをしてしまうとコミットが大きくなってしまう。コミットが大きくなるとレビュアーの負担が大きくなってしまうので、修正の内容ごとにコミットをしていく。

以下の作業を２つのコミットに分けて修正をしていく。

不要なファイルの削除

テキストエディタで articles.coffee を削除。

不要なコメントアウトの削除

articles_controller.rb の不要なコメントアウトを削除。

指摘された箇所を修正したら、そのたびに該当のコメントに返信をする。該当のコメントに返信することで、レビュアーは自分のコメントがちゃんと読まれているかの確認できる。レビューをもらった側としては修正に抜け漏れがないかのチェックになる。

プルリクエスト全体に対してのコメントに「修正しました」と返信する。

（レビュアー側の場合）LGTM を出す

修正依頼は間違いなく修正されているような場合は、「これ以上修正箇所は無いと判断した」というメッセージを伝える必要がある。その際によく使われるのが LGTM という表現である。

LGTM を出す

LGTM とは、Looks good to me の略で、「コードに問題がないのでマージしていいよ！」というプログラマー慣習。
レビュアーであれば、プルリクエストのトップページのコメントに LGTM の旨を書く。LGTM を伝えるための画像を貼り付けたりすることもある。

6. プルリクエストのマージ

これでコメント投稿機能の実装は完了。ただこれまでは copy ブランチでの操作である。ブランチは最終的に master ブランチへ結合する必要がある。これからその操作を行う。

プルリクエストをマージする

マージ

マージ（merge）は統合するという意味。機能実装のために作成したブランチを、master ブランチに統合する作業を言う。今回の場合では、このタイミングでブランチをマージすれば、次に作成するブランチにはコメント投稿機能が備わっていることになる。

マージする

LGTM をもらったら、add-posting-article-function ブランチを master ブランチにマージする。[Merge pull request]→[Confirm merge]でマージできる。

マージしたブランチを削除

マージが完了すると、GitHub 上のブランチを削除することができるようになる。これ以降 add-posting-article-function ブランチは不要なので、「Delete branch」ボタンを押して削除する。

プルする

リモートリポジトリでは copy ブランチの情報を、master ブランチにマージすることができた。次にローカルリポジトリにマージした情報を反映する必要がある。

プル

リモートリポジトリの変更をローカルリポジトリに取り込む操作のことを言う。リモートリポジトリはマージ後の情報になっているが、ローカルリポジトリではマージ前の情報のままなので、次のブランチを作成する前にプルをして情報を反映させる必要がある。

プルする

GitHbub Desktop で master ブランチに切り替え、[Fetch origin]ボタンをクリックすると、リモートリポジトリとの差分を確認する。

[Pull origin]ボタンに切り替わるので、ボタンをクリックしプルする。

これでローカルリポジトリも作業ブランチをマージした状態が反映された。以上でブランチを用いた開発の流れについて一通りである。

なお、コマンドで上記の操作を行う場合は以下の流れになる。

ターミナル

1 2	$ git checkout master #masterブランチに移動する $ git pull origin master #リモートリポジトリ（origin）のmasterブランチを反映させる