新米エンジニアがGitで失敗して学んだこと
みなさん、Git使ってますか?
Gitは多人数での開発において必要不可欠といっても過言ではない便利なツールです。
しかし、どんなに便利なツールでも正しい運用方法を理解していなければ大きな失敗に繋がってしまいます。
その点を理解していなかった私は失敗から開発環境を破壊してしまいました。(対応してくださった先輩方本当にありがとうございます。)
この記事では同じ道を歩むエンジニアのみなさんの一助になればという気持ちでGit初心者だった私の失敗談をご紹介します。
この記事はアイソルート Advent Calendar 23日目の記事です。
こんにちは。
モバイルソリューショングループ1年目のakahane.tです。
昨日はyamazaki.hさんのRealmの基礎知識 〜特徴と強みの再認識〜でした。
アジェンダ
背景
新米エンジニア(私)
- Gitをまともに触り始めて半年未満
- Gitの操作にちょうど慣れてきた頃
作業環境
- 私が開発環境を破壊したときのネットワーク(略図)は以下になります。
- master
- 本番環境で実際にサービスを提供しているブランチ
- test
- 開発環境でテスターが動作確認を行うブランチ
- develop
- 開発環境でプログラマが実装・動作確認を行うブランチ
- 基本的にこのブランチで修正は行わずマージするのみ
- デバッグコードも含まれておりゴミだらけ
- feature A, B
- 機能追加・修正を行うブランチ
- このブランチで実装しdevelopブランチにマージして動作確認を行う
- どちらのブランチも私が担当したブランチでdevelopにマージする際にAとBでコンフリクトすることがわかっている
- master
失敗 Phase.1
developで動作確認がしたい
- feature Bブランチをdevelopブランチにマージして動作確認を行いたいが、コンフリクトを解消しないといけない
- 試しにdevelopブランチにfeature Bブランチをマージしてみるがやはりコンフリクトが起きる
- コンフリクトの解消のためにdevelopブランチをfeature Bブランチに取り込む
- コンフリクトを解消してdevelopブランチにマージする
失敗 Phase.2
testにマージしたい
- 失敗 Phase.1でdevelopブランチで動作確認を行い問題ないことを確認した
- 次はテスターに確認していただくために変更内容をtestブランチへ反映させる
- feature Bブランチをtestブランチへマージする
- 下図の出来上がったネットワークが示す通り、結果的にdevelopブランチをtestブランチへマージしてしまう
どんな問題になったか
developブランチは開発中に動作確認を行うブランチで、動作確認のためのログ出力や切り捨てられたfeatureブランチの修正などのゴミが残っていることもあります。
対してtestブランチは開発環境で最後の動作確認を行うブランチで、masterブランチさながらに余計なものを入れるべきではありません。
私が「失敗 Phase.1」「失敗 Phase.2」の操作を行ったことで、developブランチのゴミをfeature Bブランチに取り込んでしまいました。
そして、feature Bブランチをtestブランチにマージしたことでtestブランチを汚してしまいました。
さらに言えば、いずれfeature Bブランチをmasterブランチにマージする予定であったため、masterブランチまで汚す危険もありました。
消火作業
testブランチにマージしてすぐ、私の先輩がこの非常事態にいち早く気がつきました。
すぐに私が行った操作と現状を確認し、解決に向けて対応し始めました。
最終的には他の作業者へ被害が広がっていることを鑑みて、testブランチはmasterブランチで上書きされました。
先輩が対応に追われている間、私は私が不用意な操作をしたことで開発環境を破壊したのにも関わらず、具体的な対応を取ることができませんでした。
失敗から学んだこと
この失敗の一番の原因は確認を怠ったことです。
最初にfeature Bブランチをdevelopブランチにマージしてコンフリクトで躓いたとき、私は自分の少ない経験から判断して行動しました。
このとき、自分に知識・経験がないことを自覚し、先輩に確認していればこのような失敗は起こっていませんでした。
この失敗を通して私は以下の教訓を得ました。
- 中途半端な知識で行動することは知識が無い状態で行動することより危険であること
- 慣れない作業をするときは必ず確認すること
- 「使えること」と「正しく使えること」には大きな隔たりがあること
- 失敗の対応は初動が肝心であること
おわりに
この失敗は技術ばかりに目を向けていた私が運用にも目を向けるきっかけになる大きな転換点となりました。
失敗からは多くのことが得られ成長に繋がりますが、それでも失敗はしたくはないですね。
本記事がみなさんの一助になれば幸いです。
明日の記事はtakeuchi.wさんによる 【WebRTC】Unified Plan(Plan A)のトリセツです、お楽しみに!