GitHubとは？新人エンジニアが「最終版ファイル地獄」から抜け出すためのGit入門
山崎講師こんにちは。ゆうせいです。
今回は、新人エンジニア向けに「Git」と「GitHub」の基本を解説します。
いきなりですが、あなたのパソコンの中に、こんなファイル名はありませんか？
設計書_最新版.docx 設計書_最新版_修正.docx 設計書_最新版_最終.docx 設計書_最新版_本当の最終.docx 設計書_最新版_本当の最終_レビュー後.docx
心当たり、ありませんか？
新人エンジニアになると、ソースコードだけでなく、設計書、議事録、手順書、設定ファイル、テスト仕様書など、たくさんのファイルを扱うようになります。
最初はファイル名を工夫すれば何とかなると思うかもしれません。
でも、プロジェクトが進むほどファイルは増えます。
修正も増えます。
誰が、いつ、どこを、なぜ変えたのか分からなくなります。
そこで登場するのが、GitとGitHubです。
Gitは、ファイルやフォルダの変更履歴を管理するための仕組みです。
GitHubは、Gitで管理している内容をインターネット上で共有・管理しやすくするサービスです。
難しそうに聞こえますよね。
でも大丈夫です。
この記事では、専門用語を使いながらも、新人エンジニアがイメージしやすいように、たとえ話を交えて解説します。
なぜ新人エンジニアにGitが必要なのか
新人エンジニアがGitを学ぶ理由は、とてもシンプルです。
現場の開発では、ほぼ必ず変更履歴を管理するからです。
ソースコードは、一度書いて終わりではありません。
機能を追加する バグを修正する レビュー指摘に対応する 不要な処理を削除する 設定ファイルを変更する テストコードを追加する
こうした変更が毎日のように起こります。
もしGitがなければ、変更するたびにファイルをコピーして、名前を変えて保存することになります。
これは、ノートを1ページ書き直すたびに、ノート全体をコピーして別のノートにするようなものです。
すぐに机の上がノートだらけになりますよね。
Gitを使えば、ファイルをコピーしなくても、変更の履歴を残せます。
つまり、今のファイルは1つのまま、過去の状態を裏側に保存しておけるのです。
Gitは「ゲームのセーブ機能」に近い
Gitを初めて学ぶときは、ゲームのセーブ機能で考えると分かりやすいです。
RPGをプレイしているとき、ボス戦の前にセーブしますよね。
もし負けても、セーブした場所からやり直せます。
Gitも似ています。
作業が一区切りついたタイミングで、現在の状態を保存します。
この保存を「コミット」と呼びます。
コミットとは、変更内容をGitに記録することです。
commit = save point
日本語で言えば、コミットは「作業の区切りをセーブポイントとして記録すること」です。
たとえば、ログイン機能を作っているとします。
途中で次のような区切りができます。
ログイン画面を作成した 入力チェックを追加した ログイン成功時の処理を追加した エラー表示を修正した テストコードを追加した
この区切りごとにコミットしておくと、後から変更履歴を追いやすくなります。
「どこでおかしくなったのか」も確認しやすくなります。
セーブしないままゲームを進めるな。
開発でも、こまめにコミットしましょう！
GitHubは「チームで使える保管場所」
Gitは、自分のパソコンの中だけでも使えます。
ただ、チーム開発では、自分だけが履歴を持っていても不十分です。
他のメンバーとコードを共有する必要があります。
そこでGitHubを使います。
GitHubは、Gitで管理しているプロジェクトをオンライン上に置き、チームで共有できるサービスです。
たとえるなら、Gitが「自分のノートに変更履歴を残す仕組み」だとしたら、GitHubは「チーム全員が見られる共有本棚」です。
| 用語 | 役割 | たとえ |
|---|---|---|
| Git | 変更履歴を管理する仕組み | セーブ機能付きノート |
| GitHub | Gitの内容を共有・管理するサービス | チームで使う共有本棚 |
新人エンジニアは、まずこの違いを押さえましょう。
Gitは仕組み。
GitHubは、その仕組みを使いやすくする場所です。
リポジトリとは何か
Gitを学ぶと、まず「リポジトリ」という言葉が出てきます。
リポジトリとは、Gitで管理するプロジェクトの入れ物です。
よく「リポ」と略されます。
たとえば、Webアプリを作る場合、フォルダの中にはいろいろなファイルがあります。
HTMLファイル CSSファイル JavaScriptファイル 画像ファイル 設定ファイル README テストコード
これらをまとめて管理する入れ物がリポジトリです。
学校の文化祭で考えてみましょう。
クラスの出し物を準備するとき、台本、買い出しリスト、ポスター、役割表、予算表などが必要になります。
それらを全部まとめた「文化祭準備フォルダ」があると便利ですよね。
リポジトリは、そのプロジェクト版です。
repository = project folder with history
日本語で言えば、リポジトリは「変更履歴ごと管理されるプロジェクトフォルダ」です。
ブランチとは何か
次に重要なのが、ブランチです。
ブランチとは、作業を分岐させるための仕組みです。
ブランチは英語で「枝」という意味です。
木の幹から枝が分かれるように、プロジェクトの本線から別の作業線を作ります。
たとえば、今動いているアプリがあります。
そこに新しく「パスワード再設定機能」を追加したいとします。
いきなり本線を直接変更すると、失敗したときに困ります。
そこで、新機能用のブランチを作ります。
main
↓
feature-password-reset
日本語で言えば、mainという本線から、パスワード再設定機能用の作業場所を枝分かれさせるイメージです。
ブランチを使うと、失敗しても本線に影響しにくくなります。
これは、料理の試作品を別皿で作るようなものです。
本番の鍋にいきなり大量のスパイスを入れると、失敗したときに戻せません。
でも、小皿に取り分けて試せば、失敗しても本体は無事です。
ブランチは、開発における小皿です。
mainブランチは「完成版の置き場」
多くのプロジェクトでは、mainという名前のブランチが使われます。
mainブランチは、基本的に安定した状態を置く場所です。
新人エンジニアが最初に覚えるべきルールがあります。
mainに直接書き込まない。
もちろん現場によって運用は異なりますが、基本的には作業用ブランチを作り、そこで変更してからmainへ取り込む流れが一般的です。
main
↓
作業用ブランチを作る
↓
変更する
↓
レビューを受ける
↓
mainに取り込む
この流れにすると、チーム全体のコードを安全に保ちやすくなります。
mainは、文化祭当日に配る完成版の台本のようなものです。
思いつきの修正を直接書き込むと、全員が混乱します。
修正案は別紙で作り、確認してから完成版に反映しましょう。
プルリクエストとは何か
GitHubでよく使う機能に、プルリクエストがあります。
プルリクエストは、作業用ブランチで行った変更を、mainなどの本線に取り込んでもらうための提案です。
よく「PR」と略されます。
プルリクエストは、ただの提出ではありません。
レビューの場でもあります。
新人エンジニアが作業したコードを先輩が確認し、コメントを付け、必要なら修正してから取り込みます。
| 流れ | 内容 |
|---|---|
| 1 | 作業用ブランチで修正する |
| 2 | コミットする |
| 3 | プルリクエストを作成する |
| 4 | 先輩やチームメンバーがレビューする |
| 5 | 必要に応じて修正する |
| 6 | 問題なければmainに取り込む |
プルリクエストは、レポート提出に似ています。
先生に提出すると、赤ペンでコメントが返ってくることがありますよね。
そのコメントを見て直し、完成度を上げる。
開発現場でも同じです。
コードレビューは怒られる場ではありません。
品質を上げ、チームの知識を共有する場です。
Gitがあると何が嬉しいのか
ここまで用語を説明してきました。
では、Gitを使うと具体的に何が嬉しいのでしょうか。
| メリット | 説明 |
|---|---|
| 過去に戻れる | 変更前の状態を確認したり、戻したりできる |
| 誰が変更したか分かる | 変更者、日時、内容を追跡できる |
| チームで安全に作業できる | ブランチを分けることで作業の衝突を減らせる |
| レビューしやすい | プルリクエストで変更内容を確認できる |
| 失敗を恐れず試せる | ブランチで新しい案を試しやすい |
特に新人エンジニアにとって大きいのは、「失敗しても戻れる」という安心感です。
プログラミングの学習では、何度も試行錯誤します。
うまく動いた状態を残しておけば、新しい修正で壊れても戻れます。
これは、料理でいう「味見前の状態を保存できる」ようなものです。
もし調味料を入れすぎても、元の味に戻せるなら、安心して挑戦できますよね。
新人エンジニアがつまずきやすいポイント
Gitは便利ですが、最初はつまずきやすいです。
よくあるつまずきを見ておきましょう。
| つまずき | 原因 | 対策 |
|---|---|---|
| 用語が多くて混乱する | リポジトリ、コミット、ブランチなどが一気に出る | まず5つだけ覚える |
| コマンドが怖い | 黒い画面に慣れていない | 最初はGUIツールや研修環境で操作する |
| コミットの粒度が分からない | どのタイミングで保存すべきか迷う | 意味のある作業単位で区切る |
| コンフリクトが怖い | 同じ箇所を複数人が変更すると衝突する | 落ち着いて差分を見て、どちらを残すか確認する |
| mainに直接変更してしまう | ブランチ運用に慣れていない | 作業前に必ずブランチを確認する |
最初から完璧に理解しようとしなくて大丈夫です。
Gitは、自転車のようなものです。
説明を読むだけでは乗れるようになりません。
少し怖くても、実際に手を動かすことで慣れていきます。
まず覚えるべきGitの5つの言葉
新人エンジニアは、最初に次の5つを覚えましょう。
| 用語 | 意味 | たとえ |
|---|---|---|
| リポジトリ | 履歴管理するプロジェクトの入れ物 | 作品フォルダ |
| コミット | 変更を記録すること | ゲームのセーブ |
| ブランチ | 作業を分ける線 | 試作用の別ルート |
| main | 安定版を置く本線 | 完成版の台本 |
| プルリクエスト | 変更を取り込んでもらう提案 | レビュー依頼 |
まずはこの5つで十分です。
細かいコマンドは後から覚えれば問題ありません。
Gitの基本的な作業イメージ
Gitの流れを、かなりざっくり書くと次のようになります。
リポジトリを用意する
↓
作業用ブランチを作る
↓
ファイルを変更する
↓
コミットする
↓
GitHubに送る
↓
プルリクエストを作る
↓
レビューを受ける
↓
mainに取り込む
日本語で言えば、プロジェクトの入れ物を作り、本線とは別の場所で作業し、変更を記録し、共有し、レビューを受けてから完成版に反映する流れです。
この流れに慣れると、開発現場の会話が一気に分かりやすくなります。
この修正、ブランチ切って対応しておいて コミットメッセージをもう少し具体的にして プルリク出したらレビュー依頼して mainにマージする前にテスト通して
最初は呪文に聞こえるかもしれません。
でも、用語の意味が分かると普通の会話に聞こえるようになります。
AI時代にGitがさらに重要になる理由
最近は、AIを使ってコードやドキュメントを作る場面が増えています。
新人エンジニアでも、AIに次のような依頼をすることがあるかもしれません。
このコードをリファクタリングして READMEを作って テストコードを追加して エラーの原因を調べて 設定ファイルを整理して
リファクタリングとは、プログラムの動きは変えずに、コードの読みやすさや保守しやすさを改善することです。
AIは便利ですが、必ず正しい変更をするとは限りません。
一度にたくさんのファイルを変えることもあります。
だからこそ、変更前の状態を保存しておくことが重要です。
GitでコミットしてからAIに作業させれば、もし変な変更が入っても戻しやすくなります。
AIを使う前にセーブする。
これは、これからの新人エンジニアにとって大事な習慣になります。
Gitを使うときの注意点
Gitは便利ですが、注意点もあります。
| 注意点 | 理由 | 対策 |
|---|---|---|
| 機密情報を入れない | 履歴に残ると削除が難しい | パスワードやAPIキーは別管理する |
| 大きすぎるファイルを入れない | リポジトリが重くなる | 画像や動画は管理方法を確認する |
| コミットメッセージを雑にしない | 後から変更理由が分からない | 何をなぜ変えたか書く |
| 作業前に最新状態を確認する | 古い状態で作業すると衝突しやすい | 作業開始前に取り込みを行う |
| 分からないまま強制操作しない | 履歴や変更を壊す可能性がある | 先輩に確認してから操作する |
特に、パスワードやAPIキーをGitHubに上げてしまうミスには注意してください。
APIキーとは、外部サービスを利用するときの合鍵のようなものです。
合鍵をインターネット上に置いたら危険ですよね。
新人のうちは、設定ファイルを追加するときに「公開してよい情報か」を必ず確認しましょう。
Git学習のおすすめステップ
新人エンジニアがGitを学ぶなら、次の順番がおすすめです。
| ステップ | 学ぶこと | 目標 |
|---|---|---|
| 1 | GitとGitHubの違い | 仕組みとサービスを区別できる |
| 2 | リポジトリとコミット | 変更を記録できる |
| 3 | ブランチ | 本線と作業場所を分けられる |
| 4 | プルリクエスト | レビュー依頼の流れを理解する |
| 5 | コンフリクト対応 | 衝突が起きても落ち着いて対応できる |
| 6 | チーム運用ルール | 現場の開発フローに合わせられる |
最初から難しいコマンドを全部覚える必要はありません。
まずは、変更して、コミットして、共有して、レビューを受ける流れを体験しましょう。
1回体験すると、かなり理解しやすくなります。
練習におすすめの題材
Gitの練習は、いきなり大きな開発プロジェクトでやる必要はありません。
小さな題材で十分です。
自己紹介ページ 学習メモ 読書メモ HTMLとCSSの練習ファイル JavaScriptの小さなサンプル 研修中の日報テンプレート
おすすめは、自己紹介ページです。
理由は、変更内容が分かりやすいからです。
名前を追加する 趣味を追加する CSSで色を変える 画像を追加する レイアウトを修正する
こうした小さな変更ごとにコミットすると、Gitの感覚がつかめます。
Gitは、怖いものではありません。
毎日の作業を安全に進めるための道具です。
よくある誤解
| 誤解 | 実際 |
|---|---|
| Gitは上級者だけが使うもの | 新人こそ早めに慣れた方がよい |
| GitHubはコードだけを置く場所 | README、設計メモ、ドキュメント管理にも使われる |
| コミットは作業が全部終わってからするもの | 意味のある区切りごとに行う |
| レビュー指摘は怒られている | 品質向上と学習のためのフィードバック |
| コンフリクトは起きたら終わり | 落ち着いて差分を確認すれば解消できる |
特に大切なのは、レビュー指摘の受け止め方です。
新人のうちは、プルリクエストにコメントが付くと落ち込むかもしれません。
でも、レビューは成長のチャンスです。
自分では気づけなかった観点を学べます。
コードの品質も上がります。
コメントが付いたら、学びのメモに残しましょう。
新人エンジニアが今日からできること
この記事を読んだだけで終わらせず、今日から小さく始めましょう。
1. GitとGitHubの違いを説明できるようにする 2. リポジトリ、コミット、ブランチ、プルリクエストの意味を覚える 3. 小さな練習用フォルダを作る 4. 変更を1つ加える 5. コミットする 6. 変更履歴を見る
最初の目標は、完璧に使いこなすことではありません。
「変更を記録する感覚」をつかむことです。
Gitは、触った回数だけ慣れます。
自転車と同じです。
最初はふらついて当然です。
でも、少しずつ体が覚えていきます。
まとめ
Gitは、ファイルやフォルダの変更履歴を管理するための仕組みです。
GitHubは、Gitで管理している内容をチームで共有しやすくするサービスです。
新人エンジニアにとって、GitとGitHubは避けて通れない基礎スキルです。
最終版ファイルを増やし続ける管理方法には限界があります。
Gitを使えば、ファイルを何個もコピーしなくても、変更履歴を安全に残せます。
| 用語 | 新人向けの理解 |
|---|---|
| Git | 変更履歴を残す仕組み |
| GitHub | 変更履歴をチームで共有する場所 |
| リポジトリ | 履歴管理するプロジェクトフォルダ |
| コミット | ゲームのセーブポイント |
| ブランチ | 試作用の別ルート |
| プルリクエスト | レビューして取り込んでもらう提案 |
一言でまとめるなら、Gitは「安心して変更するための道具」です。
失敗しても戻れる。
誰が何を変えたか分かる。
チームで安全に作業できる。
この安心感があるから、エンジニアは新しい変更に挑戦できます。
change
↓
commit
↓
branch
↓
pull request
↓
review
↓
merge
日本語で言えば、変更し、記録し、作業場所を分け、レビューを依頼し、確認後に本線へ取り込む流れです。
今後の学習では、まずGitの基本操作、GitHubの画面操作、コミットメッセージの書き方、ブランチ運用、プルリクエスト、コンフリクト解消、チーム開発ルールの順に学ぶとよいです。まずは小さな練習用フォルダで、1日1回コミットするところから始めてみましょう！
投稿者プロフィール
