Git / GitHub の使い方 - リモート編
Git用語の定義
gitを使う上で、その用語を知ることは極めて重要です。
以下にいくつか頻出の単語を書きだしておきました。
今後はこれらを用いて解説していきます。
- リポジトリ
gitによって管理されているファイルシステムのこと。commitされたファイルが記録される。 - リモート リモートリポジトリの略。外部サーバーなどにおいてあるレポジトリのこと。
- ローカル ローカルリポジトリの略。手元にあるレポジトリのこと。もしくは、手元の環境のこと。
- コミット
git commitすること。意識高い系っぽい。commitでプロジェクトにコミットや。 - プッシュ
git pushすること。つまり、リモートリポジトリに手元の変更を知らせること。詳しくは後述。
Gitの使い方 - リモートリポジトリとの通信・同期
手元のパソコンでいくらバージョン管理をしても、パソコン自体が破壊されては元も子もないですよね。
SSDの破損・パソコンの物理的損害などによる完全なるファイルの破壊を防ぐために、gitを使うことで遠隔サーバーとファイルを同期させることができます。
以下では、そのようなサーバーを提供するサービスの一つであるGitHubを用いて説明をします。
GitHubでリモートリポジトリを作る
GitHubのユーザー登録GitHubのユーザー登録を済ませておきましょう。 GitHubにアクセスし、ユーザー登録をします。新しいリポジトリを作る ユーザー登録が済んだら、Newとか新規、もしくはこのリンクを踏んで新しいリポジトリを作りましょう。 名前はなんでもいいです。public / private もどちらでもいいです。ただし、publicな状態であればそのあと上級生が助けやすくなるのではないかと推察されます。
これで終わりです！簡単でしたね。
余談ですが、このサークルのorganizationにも入っておきましょう。 Privateなリポジトリなどもあったり、サークルで取り組んでいるプロジェクトに参加できたりします。 もし入りたければ、部長のShinonomeくんとか、わしunagi_dogとか、アクティブなメンバーにtwitterないしdiscordで連絡してくれるとたぶん入れると思います。
リモートリポジトリにプッシュしてみる
GitHub側でリポジトリが生成できたので、ローカルリポジトリの状態をリモートに反映させましょう。
まず、ローカルリポジトリ（この語がわからなければGit用語の定義へ！）にリモートリポジトリを登録しましょう。
GitHubでは左上の緑のCloneボタンを押すとURLが表示されるので、
git remote add origin (URL)
を入力します。
この段階でリモートリポジトリが登録できました。
では、リモートリポジトリにローカルの状態を反映させます。 初回は以下のコマンドを使います。
git push --set-upstream origin master
二回目以降は以下になります。
git push
このコマンドを打ち終わったら、GitHubに戻って手元でコミットしたファイルが反映されていることと、リポジトリの右上にコミットの数が書いてあることを確認しましょう。
これで手元での管理とリモートとの同期は終わりです！お疲れ様でした！
開発手法とミスを防ぐ工夫
でも、実際の開発でmasterないしmainにプッシュし続けていいのでしょうか。少し考えてみましょう。そのような開発の方法では、以下のようなリスクを背負い込むことになります。
- 挙動がおかしくなるようなプログラムが混入する
- 破壊的な変更が起きてしまう。プロジェクトが破壊される。
これらを防ぐために、どのような手法を取ればよいのでしょうか。以下では、このサークルが採っている手法と個人的に重要だと思う手法を紹介します。
特定のブランチのプッシュ・差分確認
ローカルにクローンしたあとに、ブランチを切り替えて開発しましょう。mainまたはmasterでファイルの変更などを行うと、いままで他の人たちが時間を割いて築いてきたプロジェクトの破壊に繋がりかねません。ブランチの切り替えについては、ブランチについて - ブランチ を切る / 移動するを参照してください。
また、自分が行った変更を監視しましょう。一時的な変更を戻し忘れたり、ファイル削除が失敗したままだったりすることがままあります。その状態でたまたまレビューをすり抜けてしまうと、サイトが動いてはいてもh1のバカでかい文字で本文が書かれたりします。git diff (branch) HEADなどを使って確認していきましょう。
プルリクエスト
もちろん自分でチェックすることも大事ですが、複数人で行うようなプロジェクトの場合は他の人に差分のレビューをお願いしましょう。GitHubにはこのレビューを行うためのPull Request (以下プルリクエスト)という仕組みがあります。RICORA Programming Teamのブログでは、実際にサイトに反映するmainというブランチに他のブランチをマージする際に使われています。
プルリクエストは以下の手順で行います。
(プルリクエストを出すユーザー）
ローカルのブランチをリモートにプッシュする。初回は
git push (branch名) --set-upstream origin (branch名)二回目以降は
git push (branch名)です。
GitHubにアクセスする、
ghコマンドを使うなどでプルリクエストを出す どういうプルリクエストなのかを書けばいいです。どのような変更を行ったかがわかるように書くとレビューしやすくていいと思います。レビュー時にコメントなどがついた場合は返答する。
(レビューする側)
動作を確認する
プルリクエストが出されているブランチをクローンして、動作を確認します。ファイルの差分も見るといいでしょう。 とても大切なのが、実際に実行されている状態を確認することです。このブログのようにグラフィックスが関係するようなものであれば、モバイル版の画面サイズなどでどのように表示されているかも確認できるといいと思います。
コメント・認可
問題がない場合 プルリクエストが出されているブランチをmainにマージしてもいいなら、Approve(認可)ボタンを押します。その後マージするための画面が出てくるので、"Commit & Merge"を選択してマージします。
問題があった場合 プルリクエストにコメントを残しましょう。その後返信や追加のコミットがあった場合、レビューをまた行ったり、動作を確認したりするなどで対応しましょう。
この仕組みを利用すること自体は難しくないのですが、マージする側にも責任が生じます。しっかりとレビューを行って、成果物やブログを破壊しないようにしましょう。
テスト
複雑なプログラムを書く場合、プログラムをテストしましょう。プログラムの種類によりますが、意図しない挙動は意図しない使われ方の元です。バグを使った侵入手法もあります（例えばこういうのとか)。人間がプログラムを読むだけで全てのバグに気づくのは不可能なので、テストを使って効果的にバグを検出していきましょう。
実際のテスト手法には以下のようなものがあります。
単体テスト 機能単体のテストを行う。
複合テスト 機能全体のテストを行う。WebだとSeleniumとかを使うのかな？
これらを自動化してくれるのが CI/CD (Circular Integration / Circular Delivery) というものです（正確にはCircular Integrationの部分)。例えば、このwikiがおいてあるブログでもGitHub Actionsが走っていて、PRとかmergeの際にコンパイルなどが通らないとmergeできないようになっているはず。使いすぎると課金されたりするので気をつけましょう。
プログラミング言語側でもテストをサポートしてくれていると思います。Pythonにはunittestというモジュールがあったり、RustだとプロジェクトマネージャのCargoにCargo testというテス卜機能が組み込まれています。うまく使って開発していきましょう。
イシューからはじめよ？
実際にプロジェクトに参加する際、何から手をつければいいかわからないかも知れません。その場合、GitHubのプロジェクト欄からイシューを選び、それを読んで自分に対応できるものから対応していきましょう。issueの緊急度が高いもの（たぶんそういうラベルが貼ってある）から対応していただけると助かります。
また、プロジェクト上で何らかの課題を見つけて（例：記事の誤字、アイコンがおかしい、リンク切れなど）、自分で修正できない・時間がないなどの事情がある場合、イシューを新規作成してください。タイトルと内容を書いてから、ラベルを適切に設定していただけると助かります。
おわりに
最後に練習用リポジトリで練習をしてみましょう。ミスをしても気にしないでください。実践を通じてgit / GitHubに慣れ親しんでいきましょう！