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