新人エンジニアがGitの概念理解につまずいた話

配属後まもなく、アプリケーション開発案件に携わることになりました。

私は学生時代のプログラミング経験も乏しく、 最初に直面したのがソースコードの共有・管理方法でした。

当初は、SharePointを使ってソースコードを共有する運用でした。 ファイルを置いて、更新したらアップロードする、というシンプルな形です。

同時編集のしづらさや履歴管理の弱さといった不便さはあるものの、 操作自体は直感的で分かりやすく、 配属直後の自分にとっては「とりあえず使える」という安心感がありました。

GitHubの導入

一方で、チームの開発環境は全面的に GitHub に切り替わり、本格的に GitHub を用いたソースコード管理が始まりました。

当時の私は GitHub という名前自体は知っていたものの、具体的にどのような仕組みで動き、どのようなことができるツールなのかまでは理解できていませんでした。

実際に使い始めてみると、用語や概念の多さに戸惑うことがしばしばありました。

• リポジトリ
• ブランチ
• コミット
• プッシュ
• プル

これらの言葉の意味や関係性を理解するだけでも時間がかかり、 単なる操作手順ではなく、「仕組みとしての構造」を理解する必要性を強く感じました。

シンプルさが恋しくなった時期

GitHubを使い始めたばかりの頃は、

• 操作ミスによるエラー
• 意図しない競合
• 何が起きているのか分からないトラブル

が続き、開発そのものよりもツール操作に神経を使う場面が多くありました。

正直なところ、

「多少不便でも、シェアポの方が分かりやすかったな」

「シンプルで戻りたくなるな」

と感じることもあり、 最初の頃はSharePoint運用に戻りたいと思ったこともありました。

コンフリクトの発生と混乱

特に苦労したのが、マージ時に発生するコンフリクトでした。

なぜエラーが発生しているのか、 どの変更が衝突しているのか、 どのように解消すべきなのかが分からず、 同じ修正作業を何度も繰り返すこともありました。

「何が起きているのかが分からないままエラーに対応する」という状況が続き、 GitHubに対して強い苦手意識を持つようになっていました。

clone / pull に対する理解不足

現在振り返ると、特に理解が不十分だったのがcloneやpullといった操作でした。

当時は、

clone：最初に実行する操作

pull：更新時に実行する操作

という表面的な理解にとどまっており、

• ローカル環境とリモートリポジトリの関係
• 自分が今どの環境（ローカル / リモート）を操作しているのか

といった基本的な構造を正しく理解できていなかったことが、混乱の原因であったと感じています。

さらに、大きな勘違いをしていたのが pull に対する認識です。

当時の自分は、 「プルリクエストを出す前に pull すると、自分の編集内容が消えてしまうのではないか」 と思い込んでいました。

そのため、

• 編集中に pull するのが怖い
• なるべく pull を避けて作業する
• 結果として差分が大きくなり、コンフリクトが増える

という悪循環に陥っていました。

今思えば、 「pull ＝ 上書きされる」という誤解からくる不安だったのだと感じています。

最後に

まだまだ勉強中ですが、これからも試行錯誤しながら少しずつ成長していけたらと思います。

次回は、GitHub Copilotを使い始めた際に感じた戸惑いや、実際に使ってみて気づいたことについて紹介できたらと思っています。