概要
業界未経験からエンジニア転職を支援するオンラインサロン「転職クエスト」にて、Railsアプリ共同開発を行った機会がありました。
そこで、ファシリテーターを務めさせてもらった際に、開発をすすめる上で全員のネックになっていたことがありました。
Git/GitHubの共同開発的な使い方がわからない。。。
なので、開発を進めるファシリテーターとして、Git/GitHubをこうやって使おうぜ！というマニュアルを用意しておこうと考えました。
本記事では共同開発 初心者さんたちに向けたGit/GitHubのフローについて紹介します！
1. アプリの個人開発のためにGit/GitHubを使ったことはある
2. コンフリクト解消のやり方を知りたい！
3. コードレビューのやり方を知りたい！
そもそも、どこがわかっていない？
Git/GitHub を使って共同開発をする上で、ネックになる部分はどこか。
考えるために、これまで行ってきたGit/GitHubの使い方を振り返ってみます。
1. ローカルの master でブランチ切る
2. ブランチで作業しコミット
3. リモートにブランチをプッシュして、プルリク作成
4. GitHub 上でひとり LGTM を出して、ブランチを master にマージ
5. リモートの master をローカルの master にプル
6. 1~5を繰り返す
さて、このフローでしか開発をしてこなかった人が、共同開発で Git/GitHub を使う際に、初めて経験するのはどんなことでしょうか？
僕は、次のことだと考えました。
1. 他の人のプルリクに対するコードレビュー
2. リモートの master の変更分を、ローカルの作業中ブランチにマージ
3. その際に起きるコンフリクト解消
特に2, 3については、最新に更新された master からしかブランチを切ったことがないというのが不安の理由として挙げられます。
共同開発では、ブランチのマージによって常に master が更新されていきますので、その更新分を自分の作業中ブランチに反映する必要があります。
ここに焦点を当てて、共同開発でのコンフリクト解消、コードレビューの手順を紹介していきます！
コンフリクト解消の例
場面設定
master から同じタイミングで2つのブランチを切る
user1.branch1 : git checkout -b new,createアクションを実装
user2.branch2 : git checkout -b edit,updateアクションを実装
ちなみに今回は「ルーティングの設定」のみを取り扱っていきますのであしからず。
1. [user1] branch1でnew,createのルーティングを設定
+ resources :tweets, only: [:new, :create]
2. [user1] ローカルでコミット→リモートにブランチをプッシュ
% git add .
% git commit -m "ルーティングにnew,createを追加"
% git push origin new,createアクションを実装
3. [user1] GitHub でプルリク作成→LGTM→マージ
ここは省略します。
4. [user2] branch2 で edit,update のルーティングを設定
+ resources :tweets, only: [:edit, :update]
5. [user2] branch2 でコミット
% git add .
% git commit -m "ルーティングにedit,updateを追加"
※次にmasterブランチに切り替えますが、その前に必ずここでコミットをしてください！
6. [user2] リモート master (branch1 merged) → ローカル master にプル
# master ブランチに移動
% git checkout master
# リモートの master をローカルの master に反映
% git pull origin master
【今はこういう状態】
- master → new, createアクション
- branch2 → edit, updateアクション
7. [user2] ⚠コンフリクト ローカルmaster→branch2にマージ
# 作業中ブランチに移動
% git checkout edit,updateアクションを定義
# ローカルのmasterを作業中ブランチにマージ
% git merge master
【コンフリクト発生の様子】
- Head : 現在、作業中のブランチ (branch2)
- master : マージしたローカルのmasterブランチ
8-1. [user2] コンフリクトの解消
# 編集後
% git add .
% git commit
(デフォルト名 : Merge branch 'master' into edit,updateアクションを定義)
基本的に、masterと作業中ブランチのログをどちらも残し、必要な形に変えればそれでOKです。
コミットするとデフォルトでこのブランチがマージされたよ！というコミット名になります。
【※コンフリクト解消後のGitHub Desktopの画面】
▶commit Mergeを押せば、デフォルトのコミット名でコミットされる...はず
8-2. [user2] わからないのでとりあえずmergeを取り消したい！
もし「コンフリクトこわい！ 一旦戻したい！」という方にはこちら。
% git merge --abort
【merge取り消しの様子】
▶コンフリクト状態がリセットされます
9. [user2] branch2をリモートにプッシュ→プルリク
% git push origin edit,updateアクションを定義
小括 : コンフリクト解消
- ローカルの作業中ブランチで最新の変更をコミット
- 誰かがブランチをマージしたリモートのmasterをローカルのmasterにプル
- ブランチを切り替え、masterをマージ
- 落ち着いてコンフリクト解消→修正したらコミット
続いて、コードレビューの仕方についてです。
branch2「edit,updateアクションを定義」のプルリクに対してコードレビューをしましょう！
コードレビューの例
1. [レビュアー] プルリクURL→File changedタブ
ここで、ファイルの変更差分について確認します。
2. [レビュアー] 変更希望箇所をクリック（複数行を選択も可能）
直してほしい部分を選択して、コメントをします。
3. [レビュアー] コメントをする→Start a review
選択した部分についてのコメントを記載して下さい。
4. [レビュアー] 複数ファイルにコメント→Finish your review
そのプルリクで気になった箇所にコメントを残し終えたら、Finish your reviewを押して下さい。
- conversationsに戻るとレビューが反映されています。
- これに従って、プルリク依頼者はローカルで編集 → push → 再レビュー依頼
▶今回、レビュアー側として「showアクションを追加して下さい」とコメントをしてみました。これに沿って「プルリク依頼者側」での対応をしてみましょう。
5. [依頼者側] ローカルで編集してpush
#showを追加
+ resources :tweets, only: [:new, :create, :show, :edit, :update]
% git add .
% git commit -m "showアクションを追加"
% git push origin edit,updateアクションを定義
6.[依頼者側] 修正報告
レビューに対して「showアクションを追加しました！」とコメントしましょう。
7. [レビュアー] LGTM→Resolve conversation(レビュー完了)
- File changedを確認
- OKなら（コメントした後に）Resolve conversation
8. 全部でLGTMならマージ
以上のフローを繰り返し、LGTMをもらえたらマージしましょう！
9.ローカルのmasterにプル
% git checkout master
% git pull origin master
masterの変更分 (mergeした部分) が次のように反映されます。
小括 : コードレビュー
- プルリクのFile Changedで変更差分を確認
- 必要に応じてコメント
- コメントに対してローカルブランチで作業し再レビュー
- LGTMならマージ
以上が、GitHub flowによるコードレビューの基本手順です。
まとめ
- Git/GitHubを共同開発で使うときは、最新masterを作業中ブランチにマージする場面がくる
- 変わった部分を冷静に判断し、コンフリクトを解消
- プルリクに対してはファイルの変更差分を確認し、レビューを行う
個人とは違う部分が多く、例を出して説明するのに苦労しました。
しかし、この機会に学んでみるとGitってすごいな！と改めて思いました。
引き続き、共同開発がスムーズに進むよう、学習を進めていきたいです！