この記事について
⭐️こんな方に読んでほしい
ITスクールのRareTECHで勉強している初心者が、ハッカソンに参加しています。
ハッカソンについては「IT未経験がハッカソンに参加してみた」をご覧ください。
これからハッカソンに参加しようと思っている方、ITの勉強を始めたばかりの方に参考にしていただけたら嬉しいです。
この記事は「チーム開発に必要なGitHubと仲良くなりたい！」の続きになります。
マージ先の設定ミスで度々誤爆→対策はルールセット
チームのGitHubは以下の流れで運用することになりました。
- チームで使用するブランチは、mainとdevelopの二つ。
- 普段は開発用のdevelopブランチを使用し、メンバーは作業用ブランチ(feature1・feature2・・・）を切って、developブランチにmargeを行う。
- アプリが完成したら、developからmainにマージする。
初心者たちの集まりなので、こんな簡単なルールでもつまずきます
mainブランチがデフォルトになっていたため、度々mainブランチにpushしちゃいました。そして、勝手にマージされる設定になっていました。
調べたところ、GitHubにはルールセットという便利な機能があるとわかりました。
以下のルールセットを適用しました。
1,ルールセットの適用
-
Pull Requestを経由する必要がある。（直接のPushは禁止）
-
force pushは禁止。
1,チームのリポジトリのsettingをクリック
2,左側のRules→Rulesetsをクリック
3,Ruleset Nameを入力。Enforcement statusをactiveにする。
4,Target branchesにルールセットを適用したいブランチが入っているか確認する（今回はdevelop)
5,Restrict deletions（Only allow users with bypass permissions to delete matching refs.特定の権限を持つユーザーのみが、ブランチを削除できるようにする）、
Require a pull request before merging(Require all commits be made to a non-target branch and submitted via a pull request before they can be merged.すべてのコミットはプルリクエスト経由で提出された後にのみマージ可能とする。Show additional settingsで承認の必要回数やその他が細かく設定可能）、
Block force pushes（Prevent users with push access from force pushing to refs.強制的なpushができないようにする）にチェックを入れる。
6,createボタンを押したら、ルールセットが適用する。
これで誤爆も最低限防ぎ、誤った操作をしても大丈夫という心理的安全性も確保できます👌
Organizationはowners権限でルールセットが作成できます。
2、デフォルトのブランチをdevelopに変更することによって、pull requestのマージ先が自動でdevelopになるように設定。
- チームのリポジトリのsettingをクリック
- Default branch をmain→developに変更する
default branchをどれにするかは、それぞれのチームによると思いますので、参考程度に読んでください。
GitHub使い始めたばかりの頃は、ここら辺が全然わからず、混乱のままpushしては、「マージ先間違えた！勝手にマージされてる！どうしようどうしよう😣」を繰り返していました。
マージ済のコミットをrevertしたら、複数のコミット履歴が紐づいており、差分が反映されなくなってしまった
開発中、基本的には概ね順調でしたが、いかんせん初心者の集まりです。
コードレビューなんてできないとは予想がついていたため、
コード書く→リモートリポジトリにpushする→プルリクエストを出す→チームの誰か１人が承認すればマージする、という流れにしておりました。
とにかく、ハッカソンの目的は技術の習得だったため、手を動かすことを最優先としておりました。そして、アプリが最終的に動く形で完成させることが最終ゴールでした。
そんな中、以下の事件が発生していました。
メンバー1：「すでにマージ済みのtaskAだけど、自分が出すtaskBの影響で、修正が発生するかも。」
メンバー2：「修正内容は大きい？小さい？」
メンバー1：「大きいと思う。」
メンバー2：「そしたら、マージ済みのtaskAを git revert して、先にtaskBをPRしてマージしてから、修正を反映して、もう一度taskAを出すよ。」
メンバー1：「OK！じゃあ、マージしたtaskAを git revertするね。」
git revertを実施。
その後・・・
メンバー3：「PR-taskAは自分が出した、taskCのコミットも含んでいたから、変更の差分が元に戻ってしまった！」
メンバー3：「もう一度taskCをPRしようとしても、変更の差分が反映しない・・・」
メンバー3：「再度developブランチから新しくtaskC-2(featureブランチ)を切って、手動で変更分を作成し、pull requestしたら差分が反映された。けれど、git revertしたtaskCは変更が多く10ファイル以上もあるから、手動で作成するのはとても大変だぞ・・・！」
状況は以下の図のようになっていました。
Gitは「taskCの変更は『commit履歴：2』で、すでに取り込んでおり、その後 git revertで取り消した。だからもう変更をマージする必要はない」と判断したみたいです。
git revertは修正前のコミットを作成する、便利な機能ですが、使うのにはとても注意が必要なことがわかりました！
この問題の対処法について。
１、git revertしたコミットを再度 git revertして、taskAとtaskCを反映させたコミットまで戻す。
- メリット：taskAとtaskCの両方の変更が反映している状況まで戻る。
- デメリット：taskBの影響を確認できていない。
２、新たにdevelopからtaskC-2ブランチを切って、手動で変更分を再作成する。
- メリット：taskCの修正を反映できる。
- デメリット：git revert前のマージでtaskCのすでに取り込んだ変更が多かったら、再度コードを書くのが大変。
今回は１を採用し、無事、taskCの変更を反映している状態まで戻すことができました。
git revertを使用する際の参考になれば幸いです・・・。
VScodeでGitのステージング、commit、pushの仕方
VScode上でGitの操作が行えたら便利ですよね。
ターミナルでのいいのですが、タブを移動するのがめんどくさい時、よくここを使っていました。
1,左の赤丸のところをクリック。
2,変更を加えたファイルが出てくるので、「＋」を押したらステージングされます。
3,コメント記載して、コミットします。
4,変更の同期を押したら、リモートリポジトリにpushされます。リモートブランチに、ローカルで作業していたfeatureブランチがなかったら、このタイミングで作ってpushもできます。
5,ファイル名を押すと左（変更前）と右（変更後）の変更が見ることができるので、細かく行単位でステージングし、コミットすることもできます。
参考：VScodeでpullrequestやissueを作成できる拡張機能もありました。
https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github
まとめ
ミスは必ず発生します。そのミスをどれだけ事前に防ぐことができるか、が作業短縮の一つの大事なことだと感じました。
参考記事一覧
GitHub公式ドキュメント
参考にさせていただいた技術記事