はじめに
若手エンジニアの方で、GitHubでmainにマージする時、『不安だな』と思ったことはないですか？
今はまだ、そこまで影響範囲が大きくない箇所を担当していますが、これから、活躍していくために、影響範囲の大きいタスクは避けては通れない道だと思っています！
タスク初め当初は、『もし自分の実装が原因で、ある機能が動かなくなったらどうしよう😨』という気持ちでしたwww（自分のコードに自信がないので）
そこで、この記事では、初心者エンジニアがマージボタンを押すときに感じる不安を和らげるため、対処するべきことを紹介します！
対象読者
- マージのボタンを押すときに、不安で手汗が出る初心者エンジニア
😅 Slackにて...
ちょうど半年前に、こう言うやりとりがありました
マージは緊張するとtimesに呟くと色んな方々が反応してくださいましたwww
ここでは、
- revertでやり直せるよ！
- マージする時は適度な緊張感をもつことは大事なこと
- やらかした数だけエンジニアは強くなる
- 失敗した時に巻き戻せるかどうかを考える
とスレッドで反応してくださいましたが、ちょっとしたことでも、勉強になりますね👀
HRBrainは、times文化なので、ちょっとしたことでもTwitterと同じ感覚でつぶやくと多くの反応が返ってきて、すごくおもしろい？🤣です！
😃 マージについて
マージとは、複数のブランチ間でコードの変更を統合するプロセスです！
※この記事でのマージの意味は、ブランチのコード変更をmainブランチに統合することとします！
マージボタン
GitHub上では、プルリクエストページに「マージボタン」があります。
このボタンをクリックすると、PRに含まれる変更がmainブランチに統合されます。
マージ前には、先輩エンジニアにコードレビューしてもらったり、CI/CD、QAエンジニアさんがテストするなどの工程があります！
CI/CDとは？
CI (継続的インテグレーション)
- ソフトウェア開発において、ビルド（ソースコードを機械言語に変換し、必要なライブラリなどを結合し、実行可能なシステムに変換する）やテストを自動化し、容易に品質管理を行うこと
CD (継続的デリバリー、継続的デプロイ)
継続的デリバリー
- 開発者によるコードの変更に対して、バグ（システム内に存在する欠陥や誤り）がないか自動的にテストし、リポジトリにアップロードすること
継続的デプロイ
- 開発者による変更をリポジトリから本番環境に自動的にリリースし、ユーザーが利用可能にすること
マージの種類
マージにも種類があります！（ここでは軽く触れます）
この機会にマージの種類も知っておくといいかもですね〜
✍️ Create a merge commit
良い点
全てのコミットとその順序が保持され、マージコミットの保持ができる
マージされたブランチの特定の変更を見つけやすい
悪い点
多くのマージコミットが履歴に加わり、履歴が読みにくくなる
✍️ Squash Merge（スカッシュマージ）
良い点
複数のコミットが一つにまとめられるため、履歴がクリーンになる
何をマージしたかマージコミットが残る
悪い点
個々のコミットの詳細が失われる
✍️ Rebase Merge（リベースマージ）
正直使ったことないです！🙇
良い点
コミット履歴が一本の直線で、理解しやすい
マージコミットが生成されないため、履歴がスッキリ！
悪い点
元のコミットのタイムスタンプや順序が変更される
本題ではないので、詳しく知りたい方はこちらを〜😏
😃 マージボタンを不安なく押すために〜
ここから本題です！
マージのボタンを不安なく押すために、準備が必要だと思っています！
備えあれば憂いなしということで、
- マージボタンを押す前についての準備
- マージボタンを押した後についての準備
の2つの視点から説明します！
💪 マージボタンを押す前についての準備
マージ前にできることを紹介します！
1. セルフレビューで自分が不安な実装をあらかじめコメントしておく
-
コードをレビューしてもらう前に、自分自身でコードを見直すことはとても重要です！
-
特に不安な実装部分については、コメントを追加し、なぜそのようなアプローチをとったのか、他に考えられる代替案はないかなどを記しておくといいかもです！
以下の記事で詳しく書いてあります！
2. わからないこと・不安なことやがあれば、積極的に質問する
-
わからない点がある場合は、先輩エンジニアに積極的に質問することが大事です！
-
自分なりの質問のテンプレートを作っておくと実装やレビューがスムーズに進むかもですね！
-
何事も準備なので、自分なりの質問テンプレート作ってみた！
質問テンプレート
以下が、（わからない）ので、ペアプロしていただけないでしょうか？ 以下が、（不安な）ので、ご教授いただけないでしょうか？ など 【わからないこと・不安なこと】 Go言語でユニットテストを書きました。 モックをどのように実装すれば良いのか理解できていません。 [URL](GitHubのコードのPermalink) 【試したこと】 Goの標準ライブラリと、パッケージのドキュメント、ブログを参考にしました。 [URL](https://github.com/golang/mock) プロダクトコードの既存のコードのこの実装を参考にしました。 [URL](GitHubのコードのPermalink) 【試した結果】 明確な実装方法がわからず、どのようにモックをテストに適用すれば良いかが理解できていません。*[URL](GitHubのコードのPermalink)とは？*
GitHubのコードのPermalinkとは、GitHub上の特定のファイルやディレクトリの特定のコミットに対する直接リンクです！
便利なので、知っておいた方がいいかもです！🙆♂️
Visual Studio Code で GitHub URL をコピーする
3. テストコードを書く
- 場合によりそうですが、テストコードを積極的に書くのも1つの手段ですね！
- ユニットテストや統合テストを通して、新しいコードが既存の機能に影響を与えていないことを確認することも大事ですね！
何をテストしたらいいの？どんなテストを書いたらいいの？という方へ
テストコードの方針について、良さげな記事貼っておきます！
💪 マージボタンを押した後についての準備
万が一、マージ後に問題が発生した場合には、どうしたらよいの？
1. revertの実施
revertとは、過去のコミットを取り消すために、新しくコミットを作成を作成して打ち消すことです！
すぐに解決策が見つからない場合は、マージされた変更を取り消す（revertする）ことができます！
timesでも、指摘いただいたように、web上でボタンぽちぽちでできるので、楽です！ミスをしているので、気持ちは楽ではないですがw
実際にrevertをやってみた
Step1 プルリクエスト(pull request)の画面を開く
Step2 マージボタン(Merge pull request)を押し、プルリクエストのマージを行う
マージされましたね！
Step3 revertの実施！
revertのボタンを押す！
過去のコミットを取り消すために、新しくコミットを作成を作成して打ち消すことなので、新しいプルリクエストの作成に行きます！
titleとdescriptionを埋めてCreate pull request！
Step5 マージコミットを打ち消す新しいプルリクエストの作成完了！
差分がいい感じなので、しっかりできていそうですね!!!🙆♂️
2. 先輩エンジニアに相談
問題を発見したら、速やかに先輩エンジニアに報告し、対応を相談します。
単独で解決しようとせず、チームで協力して対処しましょう。
といっても、問題の大きさによると思いますが
3. 原因分析と振り返り
最後は、必ず原因分析と振り返りです！
問題の原因を知り、今後同様の問題を避けるためにドキュメント化など振り返りをしましょう！
2度と同じ失敗をしないように。。。！
おわりに
今回は、マージボタンを押すことが不安な方に向けての記事を書きました！
マージのボタンはなんか、これまでやってきた実装の達成感などがあってか、なんか緊張しますよねw
それでも、マージボタンを押す際の緊張感は、準備をしっかりしておけば大丈夫だと思っています！！！
慣れは怖いので、適度な緊張感は持っていたいですね〜!
ではまた、次回の記事でお会いしましょう！👋
参考
PR
HRBrainでは一緒に働いてくれる仲間を募集しています！😁
アドベントカレンダー1記事目
アドベントカレンダー2記事目