2022/09/22に私が講師を勤めてGitHubのリポジトリを、クローンしてからmasterブランチへマージするまで流れを解説するハンズオンセミナーを行いました。
このセミナーの内容は、私が実際に業務で行っているフローをもとにやらせていただきました。この内容を身につければ実務でもスムーズにGitHubが使えるものと考えています。
少人数で行ったおかげで、途中参加者に出たエラーについても対処ができました。これも良い勉強になりましたので、セミナーの内容と合わせて紹介させていただきます。
セミナーの流れ
セミナーの流れは下記の通りで行わせていただきました。
- 参加者自己紹介（私を含め３名）
- ハンズオン開始（リポジトリはあらかじめ私が作っておいたもの）
- リモートブランチ（GitHub）のmasterブランチをクローン
- ローカルのmasterリポジトリから作業ブランチを作成
- 作業ブランチに変更を加えず、リモートブランチへプッシュ
- 作業ブランチを更新、リモートへプッシュ、プルリクエストの作成
- レビュー、修正、承認を行い、masterへマージ
あらかじめ作成したリポジトリについて
今回は勉強会前に私のほうで作成したブランチを使わせていただきました。とくに難しい設定はしていませんが、勉強する内容にあわせて下記の２点のようにしておきました。
- プルリクエストのmasterへのマージは1人以上の承認がないとできない
- コラボレーターは未招待状態
実際使用したリポジトリは下記のURLになります。勉強会後の内容になっていますので、コミットの内容も含まれています。
https://github.com/otoiron/handson220930
リモートのmasterブランチをローカルにクローン
GitHubリモートリポジトリのURLにアクセスして、クローンするためのコードを取得します。
「code」のボタンから「SSH」を選択した状態で表示されているコードをコピーし、git clone コマンドを実行します。今回は受講者が全員Visual Studio Codeを利用していたので、そちらのターミナルを開いて下記のコマンドを実行しました。
git clone git@github.com:otoiron/handson220930.gitGitHubに登録しているデータがダウンロードされればクローン完了です。
エラー発生！！クローンできない！
上記のやり方ですとクローンをSSH接続で行いましたが、参加者の一人が公開鍵の登録をしておらずエラーが発生しました。今回は時間の関係もあり、取り急ぎHTTPS接続でクローンしました。コマンドの内容は「code」→「HTTPS」からコピーしたコマンドを、git cloneにつけて行う先ほどのやりかたとかわりません。
git clone https://github.com/otoiron/handson220930.gitローカルのmasterリポジトリから作業ブランチを作成
クローンができたらローカルで作業ブランチの作成を行います。まずは現在のブランチを確認するために、git branch を実行して現在の選択されているブランチを確認しましょう。
git brach
// 結果
// * master表示された結果には「* master」が表示されます。この「*」が現在選択されているブランチを指しています。続いて git checkout コマンドで作業ブランチを作ります。新しいブランチを作るには下記のようにオプションに「-b」とブランチ名を付与して実行します。
git checkout -b feature/index-headerここではブランチ名を「feature/index-header」としました。この「feature」は開発現場でよく用いられるルールで、新しい開発や更新を行う際に付与されるものになります。GUIのSoucetreeを使っているとスラッシュ前の「feature」でディレクトリを作ってくれるので視認性が増します。
ブランチの命名規則はそれぞれの開発現場でルールがありますので、新規で参加した仕事では最初に確認しておくことをお勧めします。
エラー発生！！コマンドを叩いても何も表示されない！
参加者の一人で新しく作業ブランチを作成したところ「fatal: not a git repository (or any of the parent directories): .git」というエラーが表示されました。どうやらクローン後にクローンしてきたディレクトリに移動していなかったのが原因でした。クローン後には cd コマンドで移動することを忘れないように気をつけましょう。
エラー発生！！クローンしてきたリポジトリなのに何もできない
クローンしてきたリポジトリにも関わらず、checkoutやbranchのコマンドを叩いてもメッセージがでない、add, commit, pushもできないということが起こりました。どうやらローカルブランチで git init を間違えて実行していたようで、gitの設定が初期化されていました。
まだ更新していない状態だったので、もう一度リポジトリをクローンして対処しました。
cd クローンしてきたディレクトリ名作業ブランチに変更を加えず、リモートブランチへプッシュ
作業ブランチの作成ができたら、とりあえず何も更新せずにプッシュをして、GitHubのリモートブランチが出来ているかを確認します。まずは現在のローカルブランチで何が選択されているかを確認するために git branch を実行します。
git branch
// 結果
// master
// * feature/index-header新しく作業ブランチを作成したのと同時にそのブランチが選択されているので、「*」の位置が変更しています。ここで作業ブランチの名前をコピーし、git push コマンドを実行します。リモートブランチへのプッシュは origin をつけて実行します。
git push origin feature/index-headerセミナー内ではここで意図的にエラーを出させていただきました。冒頭でも申し上げましたがコラボレーターの設定をしていないため、参加した人が勝手にリモートブランチを作成することはできないようになっています。
実務で使用する場合はその会社のorganizationに入っていることでその権限が付与されることがあったり、管理者側で設定してもらうことで可能となる場合があります。ここでは共同開発をしたいGitHubユーザーに対してinvite（招待）を送ってCollaborator（コラボレーター）の登録をしました。
コラボレーターの設定はsettingsから
左メニューの Collaborators → Add people からGitHubのアカウント名もしくはメールアドレスで登録が可能です。追加をすると招待したユーザー宛にメールが送られますので、メールに記載されたリンクから承認画面へ進み、Accept Invitaion のボタンをクリックしてください。
承認が完了するとPending Inviteの文字が消えます。
コラボレーターの登録後、git push を実行すると無事にプッシュができます。
ちゃんとできているかどうかGitHubにアクセスして確認しましょう。
「master」となっているセレクトボックスをクリックするとブランチの一覧が表示されます。ここでは先ほどプッシュした「feature/index-header」が登録されていることが確認できました。続いてそのブランチ名をクリックして、作業ブランチにアクセスします。
まだ何も変更していないのでmasterブランチと何も変わりませんので、ファイルを更新してプッシュしていきましょう。
作業ブランチを更新、リモートへプッシュ、プルリクエストの作成
ファイルの内容を変更してプルリクエスト作成までの流れを簡単にまとめますので、順を追って作業していきましょう。
- ファイルを更新（コードの追加や修正、新規作成、削除など）
- 更新をステージングに追加
- 更新を登録（コミット）
- 登録した更新をリモートリポジトリへプッシュ
- リモートリポジトリにアクセスしてプルリクエストを作成
まずはファイルの更新です、今はgitの練習なので内容は何でも構いません。
Visual Studio Codeではgitを使っている状態でファイルに差分が出ると、左メニューのアイコンに更新されているファイル数が表示されます。
クリックをすると更新のあるファイルの一覧が表示されます。このGUIから更新をステージングに追加（git add）、更新を登録（git commit）ができるので、コマンドで実行するときの方法と合わせて紹介します。
ファイル名の上にマウスカーソルを乗せると右に表示される「＋」をクリックするとステージングに追加されます。ターミナルからコマンドで実行すると下記のようになります。
git add ファイル名続いてコミットをして変更を登録します。上部のテキスト入力エリアにコメントを入力してボタンをクリックすると完了します。コマンドで実行すると下記のようになります。
git commit -m ”コミットのコメント”これでローカルブランチに変更の内容が登録されました。
何をしているか実感が湧かないかもしれないので、変更が登録されているかを確認しましょう。更新したファイルを開いたまま、ブランチをmasterに切り替えましょう。
git checkout masterすると、更新した内容が元に戻っていることが確認できます。これは作業ブランチでは変更を登録してるけれど、masterブランチでは変更を登録していないということになります。確認ができたら作業ブランチへ戻ります。
git checkout feature/index-header続いて git push で登録した変更をリモートリポジトリへプッシュします。
git push origin feature/index-headerこの「origin」はリモートブランチのことを指しています。実行してプッシュに成功すると下記のようなメッセージが表示されます。内容を読む必要はないですが「done」がたくさん表示されていれば問題ないでしょう。
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 530 bytes | 530.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To github.com:otoiron/handson220930.git
25c8a36..72edb5b feature/index-header -> feature/index-headerプッシュができたので再度リモートリポジトリの作業ブランチへアクセスします。
すると今回は画面上部に「Compare & pull request」のボタンが表示されています。これはコミットをプッシュすると表示されるもので、ここからプルリクエストを作っていきます。
プルリクエストは登録した変更をマージ（今回はmasterブランチへ変更を登録）してもらうための準備です。プルリクエストからレビュワーが変更内容を確認し、OKであればmasterブランチへマージするという流れになります。
では、ボタンをクリックしてプルリクエストを作成します。
こちらがプルリクエストの作成画面です。タイトルと本文が入力できるようになっています。タイトルは参加しているプロジェクトや会社ごとに命名規則がある場合が多いので、新しく入る場合は前もって確認しておくと良いでしょう。本文にもルールを持っていることが多く「こういうことを書き残す」が支持されています。本文には定型文の設定も可能なので、設定があった場合はそれに沿った記述をしましょう。
ここではルールが存在しないので適当に入力していますが、本来であれば
- どういう変更をしたか
- どこをレビューして欲しいか
- 参考とした記事のURL
- このプルリクエストの内容が反映され、ブラウザ確認ができるURL
などが書かれていると良いと思います。このタイトルや本文は後で変更可能です。
プルリクエストが完成すると下記のような画面に移ります。
このブランチでは1人のレビュワーが Approve（承認）しないとマージができないように設定しているので、この時点では「Review Required（レビューが必須）」とメッセージが出ています。
コラボレーターのどなたかにレビューをしてもらうために、レビュワーの設定を行います。画面右上のReviwers 右の歯車から選択しましょう。
レビュワーに設定した人へレビューの依頼をしましょう。メールは送られているのですが、実務ではチャットツールなどでプルリクエストのURLを送ってお願いしていることが多いです。
ここでは私が他のアカウントでレビューをすることにします。レビューはコミットをクリックしてファイルの変更点を確認するのが良いでしょう。
今回はclass名をちゃんとつけることをレビューとして戻します。コメントはコードの行に挟んで記述できます。
レビューの入力を決定した時点では、まだレビューは相手に見えないPendingの状態になっています。ひとつずつ送信するのではなく、全てのコードにレビューが完了した時点で一度に送るような流れになります。
今回はひとつだけなのでこれで送信します。レビューが入ると画面右上の「Review Changes」ボタンが「を入れると「Finish Your Review」に変更され、ボタンの右にレビューの数がついています。これをクリックするとコメントとラジオボタンの選択が出てきます。コードに対してレビューを行わない場合はこちらでコメントを記載してもいいでしょう。
今回はコードの行下にレビューをつけているのでここでの入力はしないで送信します。
ラジオボタンの３つの内容は下記の通りになります。
- Comment
コメントを残すのみの選択肢です。この後に説明する承認も修正依頼もしないというレビューです。 - Approve
承認になります。このリポジトリではこちらを選択してレビューを完了すると、masterブランチへのマージができるようになります。 - Request Changes
修正を依頼します。こちらが選択された場合、コードの修正を行わないとマージをすることができないことを促します。
ここでは修正を依頼するので「Request Changes」を選択して「Submit Review」をクリックします。これでレビューが相手の画面にも反映されます。プルリクエストのトップに戻ると下記のように修正を促すメッセージが表示され、マージがブロックされています。
修正を反映して変更の登録 → コミット → プッシュを行います。修正が終わったらレビューに対してコメントを返しておきましょう。レビュワーの方が修正を確認し「Reveiw Changes」ボタンから Approve を行うとマージができる状態に変更されます。
「Merge pull request」のボタンからマージをしていきます。実案件の場合はマージを誰が担当するかを申し合わせしておいた方が無難かと思います。
コメントを編集することができますが、今回はこのままマージしてしまいます。「Confirm merge」ボタンをクリックするとマージが完了します。
プルリクエストが完了するとこのブランチを削除するかのメッセージが表示されます。変更の内容はmasterに残るのでDeleteしても問題ないかと思いますが、プロジェクトのルールによってはそうでない場合もあるかもしれませんので、確認しておくといいかもしれません。（後からでも消せます）
ローカルのmasterブランチを更新
これでリモートのmasterブランチが更新できました。この更新はまだローカルのmasterブランチには登録されていない状態になっていますので、リモートブランチから pull（プル）してきます。
ローカルの作業ブランチからmasterブランチへの切り替えを行います。
git branch master続いてリモートリポジトリに登録された変更をローカルリポジトリに取り込みます。
git pull origin masterこれでローカルのmasterブランチにも変更が反映されます。他の作業を進める場合はここから新たに作業ブランチを作って進めてください。
プロジェクトによってはmasterにはマージしない場合もありますので、新しい仕事でGitHubを使う場合は、事前に更新のフローを確認しておいた方がいいでしょう。
終わりに
今回のオンラインハンズオンセミナーではこの内容に加えて、わざとコンフリクトを起こして、どう対処するかの方法を試しました。その内容についてはまた別の記事で書かせていただきます。
ここまで読んでくださり、ありがとうございました。
コメント