こんにちは、コーディング課3回生のguuです。
GitHub解説最終回の今回は、GitHubでよくあるエラーの解決方法をまとめていきます。

最後に、GitHub解説のおまけもあります。

分からない単語があれば第1回の記事を参照してください。

コンフリクト

GitHubのエラーの9割はこいつです。

つまり、こいつのエラーの解決方法だけ知っていれば、大体なんとかなります。

解決方法

基本的にコンフリクトが起こった場合、元の状態か現在の状態どちらを適用するのか選ぶことになります。

コミットをもとに戻して、原因のファイルの変更を取り消す

このやり方は、主にプル・マージ時にコンフリクトが発覚した場合に有効です。

具体的なやり方は、第3回のコミットTipsの変更を元に戻すを参照してください。

プルリクエストで解決

このやり方は、プルリクエストを出したときにコンフリクトが発覚した場合に有効です。

まず、GitHubのコンフリクトが起こっているプルリクエストで、「Resolve conflicts」をクリックしましょう。

すると以下の画像のように、コンフリクトが起こってい変更が表示されるので、取り消したい方の変更と「test/guu」や「main」と書かれた行を消しましょう。

以下の画像では、mainのブランチの変更を残したいので、test/guuのブランチの変更を消しています。

コンフリクトが解決すると「Make as resolved」のボタンがクリックできるようになるので、クリックしましょう。

その後、マージできるようになればコンフリクト解消完了です。

ブランチを捨てる

GitHubのエラーの解決ができず、期限も近いとなったら、最悪の場合、開発中のブランチを捨てましょう。

このブランチを捨てる際には、現在のプロジェクトのコピーをとっておき、新しく作ったブランチにコピーしたファイルを適用していきましょう。

また、ファイルの適用の際には、一気にやるのではなく、コンフリクトが起こらなそうなものから機能ごとに適用していきましょう。

対策

基本的な指針は、複数人が同じファイルを触らないようにするというものです。

複数人が同じファイルを触らなければ、当然コンフリクトも起こりません。

チームメンバーとコミュニケーションをとる

一番これが重要です。

例えば、誰かが触っていそうなファイルを触るときには、まずチーム内でだれも触っていないか確認を取りましょう。

さらに、全体に関わりそうなファイルを触るときには、このファイルを触りますとチーム内で宣言をしておくことで、コンフリクトを避けやすくなります。

余計なファイルをプッシュしない

第3回のコミットTipsで述べているように、余計なファイルやフォルダをプッシュしないようにしましょう。

特に、触った覚えのないファイルは他の人が触っている可能性があるので、変更を戻すように気を付けましょう。

機能ごとにブランチを分ける

機能ごとにブランチを分けることで、現在作業中の機能がブランチを見るだけで分かります。

これにより、どのファイルを触るとまずそうなのか察しやすくなります。

また、ブランチを捨てざるを得ない状況になった時も、失う変更量を減らすことができます。

マスターブランチを直接触らない

第3回のブランチのTipsのマスターブランチで書いた通り、マスターブランチはすべてのブランチの基準なので、下手にマスターブランチで変更を行うと、すべてのブランチが影響を受けます。

機能の追加・変更などを行うときは、必ず自分のブランチで行いましょう。

おまけ

プルリクエストのレビュー

プルリクエストにレビューを書くことで、ファイルの修正箇所を明確に伝えられ、修正の適用状況もわかりやすくなります。

やり方

まず、GitHubでレビューを書くプルリクエストを開きましょう。

プルリクエストを開いたら、「Files changed」という項目から、変更されるファイルを確認します。

そして、もし修正を依頼したいファイルがあった場合、その修正してほしい行の横の＋ボタンをクリックし、レビューを書きましょう。

レビューが書けたら、右下の「Start a review」ボタンをクリックすることで、レビューを確定させます。

レビューがすべて書き終わったら、「Finish your review」ボタンをクリックしましょう。

すると、以下のようなウィンドウが出てくるので、「Submit review」ボタンをクリックしましょう。

ちなみに、ウィンドウの下にあるラジオボタンは、レビューの重要度を示しており、Comment<Approve<Request changesで優先度が高くなります。

レビューされた修正が完了した場合は、プルリクエストを開き、「Conversation」の修正依頼のコメントの下の「Resolve conversation」をクリックしましょう。

これで、修正が完了したことをチームメンバーに伝えられます。

おわりに

全4回に渡ってGitHubについて解説しました。

しかし、これらの記事ではRiG++のサークルとして使いそうな部分のみ解説しており、これでGitHubのすべてが分かるわけではありません。

また、ブランチやコミットの仕方などチームやプロジェクトによって変わるため、その場に合わせて臨機応変に対応しましょう。

長々と読んでいただきありがとうございました。