最初の研修でGitについて学んだけど..
この研修では、Gitの基本操作について一通り教わりました。そのときは正直、「なるほど、なんとなく分かったかも」くらいの感覚でしたね。でも今振り返ると、あれは “理解した” ではなく “理解した気になっていた” だけで、例えるなら、学校の授業で公式の解き方を聞いただけで、問題演習を一切していない状態に近いです。インプットはできていてもアウトプットができていないので、いざ自分でやろうとしても、手が動かない状態です。
Gitもまさにそれでした。当時の私は甘く見ていたのですが、実際に手を動かして使う機会がほとんどなかったので、「pushってこれであってるよな？なんかエラー出た！pullしてないからか？pullもできない！」みたいなことが、後々のチーム開発研修で起きてしまいます。
そもそもGitとは？
一言で説明すると、「ファイルの変更履歴を管理するためのツール」 です。
いつ・誰が・どのファイルを・どの様に変更したのかを記録することができ、差分の比較や、自分の変更と誰かの変更を合体させることもできるので、開発チームで同じソースコードを安全に編集することが可能になります。エンジニア・プログラマーとして働くなら、ほぼ100％使うと言っても過言ではないくらいの必須ツールになります。
上記のように説明されましたが、正直この時の私は全然ピンときていませんでした。「便利そうなツール」くらいの感覚だったので、今考えるとめちゃくちゃ理解が浅かったなと思います。
チーム開発研修で地獄を見た話
数人のチームで同じリポジトリを触りながら、簡単なアプリを作るチーム開発研修がありました各々担当する機能があり、完成したらマージ（一つの開発環境に自分の作った機能を統合するイメージ）するという流れでした。そこで、まず最初につまずいたのがブランチです。ブランチを切って作業するように言われたものの、その時の私は「ブランチ＝作業場所が分かれる？」くらいのふわっとした理解しかありません。研修でもなぜかまったく説明されず、とりあえずネットで調べたりAIに聞きながらやったり、完全に手探り状態でした・・・
その結果、当然うまくいくはずもなく、機能が完成してマージしようとすると、「コンフリクト」という、自分と誰かの編集が競合してしまう現象が起きます。一部のチームでも「マージできない」「環境壊れた」「誰かの変更が消えた」とカオス状態でした。対岸の火事だと思いきや、私もやらかしました。ブランチを切らずに作業していて、変なブランチからコミットしてマージしてしまいました・・・
このとき初めてGitの難しさ、怖さに気が付きました。そして、説明を聞いて「なるほど」と思うのと、実際にチームで安全に使えるのはまったくの別物でした。Gitは知識ではなく、完全に“慣れ”のツールなんだと、この研修で痛感しました。
ブランチ？コンフリクト？新卒SEの私がつまずいたポイント3選
研修や実務で実際に触ってみて、特に痛感したのが、「Gitって分からないことだらけだな…」ということでした。中でも、私が本気でつまずいたポイントは大きく3つあります。
まず一つ目が、コンフリクトです。「同じファイルを同時に編集すると競合が起きる」くらいの認識で、いざ実際に発生すると、どことどこが競合しているのか、とにかくめちゃくちゃ見にくい！どこを消して、どこを残して、どうやって確定させるのか。対処法まではまったく分かっていませんでした。それに、競合を解消する責任感みたいなのも感じてしまって、コンフリクトは本当に面倒でした。
次に、二つ目は、コマンドについてです。Gitを操るには様々なコマンドを駆使しなければならず、間違えるとかなり面倒なことになります。add？ commit？ push？ pull？ fetch？似たような単語が多すぎて、毎回「あれ、次どれだっけ…」と毎回なっていました。
そして三つ目が、作業手順が分からないことです。これが一番つまづいたポイントで、研修中、「作業前ってpullするんだっけ？」「コミットしてからpush？」「順番ミスったらどうなる？」という風にいろいろ考えた挙句、最終的には半分運ゲーでやってました。実務で、いろいろ聞きながら作業できているおかげで、全員の環境壊したり、ほかのプログラマーの作業を止めたりすることはありませんが、マージするときは今でも手が震えます。
Gitが難しいのはもちろんなのですが、今の自分の視点から見ると、チーム開発の解像度が低いことがGitの理解の浅さにつながっているように感じます。今振り返ると、どれも特別難しい話ではありません。実際に手を動かして失敗する経験が足りなかっただけでした。
研修より実務のほうが5倍身についた理由
結論から言うと、Gitは研修よりも実務のほうが身につきました。これはGitに限らずどんな勉強でもいえることなのですが、聞くより実践する方が身につく速度に圧倒的な差があります。体感5倍くらい差があったと思っています。
研修では、PDFを見ながら、コマンドの使い方だったり、用語の意味を勉強して、簡単な練習問題に取り組むというのを繰り返すだけでしが、実務に入ってからはそうはいきません。毎日のようにGitを使います。もちろん、「この操作してもいいのか？」「次どうやるんだっけ？」みたいな疑問が出てきて、pullやブランチの切り替えが失敗したとき、コンフリクトが起きたとき、めちゃくちゃ焦りますし、一つでも操作を誤ったら全体の作業が止まってしまう可能性が出てくるので、集中して取り組まなければなりません。でも、その「失敗」と「焦り」こそが一番の勉強になりました。エラーが出たら嫌でも調べるし、同じミスをしないように手順を覚えます。研修は「知識」だけ。実務は「経験＋責任」があることによって、覚えるスピードが段違いだったんだと思います。
考えると、Gitに限らず、エンジニアのスキルのほとんどが「慣れ」と「場数」だと思います。完璧に理解してから使うのではなく、使いながら理解していくものだと気が付きました。
学生のうちにやっておけばよかったGit勉強法
正直に言うと、学生のうちに「チーム開発を経験しろ」と言われてもかなり厳しい思います。情報系の学部生だったり、情報系の専門学生ではない限り、Gitを使って開発を行う経験を積むことは難しいと思っています。僕自身も、学生時代になにかアプリを開発しようと思っても、チームで開発を行うという考えは思い浮かびませんでした。だから当時は、Gitは実務に入ってから覚えればいいくらいに思っていました。しかし、エンジニアを目指すなら学生時代に少しでもGitを触っておくだけでかなり楽になります。そして、Gitをある程度触ってみて、学生でもGitの予習を実践に近い形で行う方法が、あるにはあるなと思ったので、それを紹介していきたいと思います。
一つ目は、GitHubで自分のリポジトリを作って、日常的にコミットすることです。どんな小さなコードでもいいので、とにかく「変更・commit・push」この流れを何度も繰り返すことをオススメします。これだけでGitの雰囲気だったり、操作にはある程度慣れていくと思います。
二つ目は、あえてブランチを作って作業することです。mainブランチだけで作業するのではなく、別のブランチを作って、そこで作業して、mainブランチにマージする。最初は意味が分からなくてもいいので、「とりあえず手順通りやってみる」ことが大切です。ブランチとマージに慣れているだけで、実務のハードルはかなり下がります。
三つ目は、わざと失敗してみることです。コンフリクトを起こしてみたり、履歴を壊してみたり、
「これやったらどうなるんだろう？」を試す。実務だと怖くてできないことも、個人環境ならいくらでもやり直せます。実はこの “失敗経験” がいちばん身につきます。完璧に理解してから始める必要はありません。コマンドを全部暗記する必要もありません。なんとなく触って、ミスして、調べて、また触る。結局これが、いちばんの近道だと思います。
超端的に言うと、「参考書を見るより、Gitを触る」です。
【結論】Gitは「理解する」より「慣れ」
ここまで読んでいただきありがとうございます。
いろいろ書いてきましたが、Gitは天才しか扱えないツールでは決してありません。設計やプログラミングのほうが100倍難しいです。だからもし今、「難しそうだな…」と思っているなら、まずは小さな個人開発でいいので、毎日Gitを触ってみてください。きっと気づいたら、「あれ、普通に使えてるな」ってなっているはずです。この記事が、あなたがGitに慣れるきっかけになれば嬉しいです。ちなみに、Gitのコマンドや仕組みについては、別記事で詳しく解説する予定です。「ちゃんと理屈も知りたい」という方は、そちらもぜひ読んでみてください。僕もまだまだ勉強中ですが、一緒に少しずつ慣れていきましょう！
下記内部リンク
Gitの仕組み※現在作成中
コメント