Git・GitHubの使い方を初心者向けに解説｜フリーランスに必須のバージョン管理

2026年4月5日

山口彩花

この記事のポイント

✓Git・GitHubの使い方を初心者向けにわかりやすく解説
✓インストールから基本コマンド
✓プルリクエストの作成まで

フリーランスエンジニアになって最初に恥をかいたのが、Gitだった。クライアントから「GitHubのリポジトリにプルリクエスト出してください」と言われて、「プルリクエスト…？」と固まってしまった。前職のSIerではSVN（Subversion）を使っていて、Gitはほぼ触ったことがなかったのだ。

あの日から5年。今ではGitなしの開発は考えられないし、GitHubのプロフィールはフリーランスの名刺代わりになっている。振り返ると、Gitの学習は「最初の壁」を越えればそんなに難しくなかった。この記事では、あの頃の自分に教えるつもりで、GitとGitHubの基本を解説する。

Gitとは何か

Gitはバージョン管理システム。ファイルの変更履歴を記録して、いつでも過去の状態に戻れる仕組みだ。

Wordで「提案書_v1.docx」「提案書_v2_修正済み.docx」「提案書_最終版_本当の最終版.docx」とファイルを増やした経験は誰にもあるはず。Gitを使えば、1つのファイルで変更履歴を全て管理できる。

プログラミングでは、コードの変更が予期せぬバグを生むことが日常的にある。Gitがあれば、「昨日まで動いていた状態」にワンコマンドで戻せる。保険としてのGitは、フリーランスの精神的な安定にも直結する。

GitとGitHubの違い

初心者が混同しやすいポイントなので、最初に整理しておく。

	Git	GitHub
何か	バージョン管理ツール	Gitのホスティングサービス
場所	自分のPC（ローカル）	インターネット上（リモート）
料金	無料	個人利用は無料
役割	変更履歴の管理	チーム開発、コード共有、ポートフォリオ

Gitはツール、GitHubはそのツールを活用するサービス。GitHubの代わりにGitLab、Bitbucketなどを使うこともあるが、フリーランスならGitHub一択でいい。案件の9割以上がGitHubを指定してくる。

環境構築：Gitのインストール

Macの場合

ターミナルを開いて以下を実行するだけ。

xcode-select --install

これでGitがインストールされる。確認は git --version で。

Windowsの場合

Git公式サイト（git-scm.com）からインストーラをダウンロードして実行。途中の選択肢はデフォルトのままで問題ない。Git Bashというターミナルが一緒にインストールされるので、以後はそこからGitコマンドを実行する。

初期設定

インストール後、名前とメールアドレスを設定する。これはコミット（変更の記録）に「誰がやったか」を残すため。

git config --global user.name "あなたの名前"
git config --global user.email "あなたのメール"

基本の5コマンド

Gitには数十のコマンドがあるが、日常的に使うのはたった5つ。

1. git init：リポジトリの作成

プロジェクトのフォルダでこのコマンドを実行すると、Gitによる管理が始まる。

cd my-project
git init

2. git add：変更のステージング

変更したファイルを「次のコミットに含める」と指定する操作。

git add index.html        # 特定ファイルを追加
git add .                  # 全ての変更を追加

3. git commit：変更の記録

ステージングした変更を、メッセージ付きで記録する。

git commit -m "ヘッダーのデザインを修正"

コミットメッセージは何を変えたかを簡潔に書く。「修正」「更新」だけだと、後から見たときに何の変更かわからなくなる。自分も最初は「fix」としか書かなくて、1ヶ月後に「何をfixしたんだ…」と頭を抱えたことがある。

4. git push：リモートに送信

ローカルのコミットをGitHubに送信する。

git push origin main

5. git pull：リモートから取得

他の人がGitHubにpushした変更を、自分のローカルに取り込む。

git pull origin main

この5つのコマンドを覚えるだけで、個人開発は十分にこなせる。自分はフリーランス1年目のほとんどの案件を、この5コマンドだけで乗り切った。

ブランチ：Gitの真価

ブランチは、Gitが本当に威力を発揮する機能。メインのコードに影響を与えずに、新機能の開発やバグ修正を並行して進められる。

ブランチの基本操作

git branch feature/login    # ブランチ作成
git checkout feature/login  # ブランチ切り替え
git checkout -b feature/login  # 作成と切り替えを同時に

よく使うブランチ運用

フリーランスの案件では、以下のシンプルな運用で十分。

main：本番環境のコード。直接コミットしない
develop：開発中のコード。テストが通ったらmainにマージ
feature/xxx：個別の機能開発。developから分岐し、完了したらdevelopにマージ
fix/xxx：バグ修正用のブランチ

「ブランチを使いこなすのは中上級者」と思われがちだけど、フリーランスならブランチ運用を理解していることは最低条件。クライアントから「featureブランチ切ってPR出して」と言われて対応できないと、信頼を失う。

GitHubの使い方

アカウント作成

github.comにアクセスして、メールアドレスとパスワードで登録。無料プランで十分。

リモートリポジトリの作成

GitHubのダッシュボードから「New repository」をクリック。リポジトリ名を入力して作成する。その後、ローカルのプロジェクトと紐づける。

git remote add origin https://github.com/username/repo-name.git
git push -u origin main

プルリクエスト（PR）の作成

フリーランスのチーム開発で最も重要な機能。ブランチでの変更内容をレビューしてもらい、mainブランチにマージする流れ。

featureブランチで開発・コミット・push
GitHub上で「New pull request」をクリック
変更内容の説明を書く
レビュアーを指定して提出
レビューで指摘を受けたら修正してpush
承認されたらマージ

PRの説明には「なぜこの変更をしたのか」「どういう動作になるか」「テストの結果」を書く。これがしっかりしているフリーランスは、クライアントの信頼度が格段に上がる。

.gitignoreの設定

リポジトリに含めたくないファイルを指定するファイル。これを正しく設定しないと、環境変数（.env）やnode_modulesがGitHubに公開されてしまう。

## .gitignore
node_modules/
.env
.DS_Store
dist/
*.log

特に.envファイルは絶対にコミットしないこと。APIキーやパスワードが公開されると、セキュリティインシデントに直結する。自分のフリーランス仲間にも、.envをpushしてしまってAWSの請求が数十万円になった人がいる。

GitHubプロフィールをポートフォリオにする

フリーランスにとって、GitHubプロフィールはそのまま技術力の証明になる。

効果的なプロフィールの作り方

リポジトリのREADMEを充実させる: プロジェクトの概要、技術スタック、スクリーンショットを記載
コントリビューションの草（Contribution Graph）を緑にする: 定期的にコミットしている=継続的に開発している、というアピール
pinned repositories: 代表作を6つまでトップに固定できる。一番見せたいプロジェクトを選ぶ

@SOHOのお仕事ガイドによると、エンジニア職種ではGitHubのアクティビティが選考で重視されるケースが増えている。特にWebエンジニアやデータエンジニアの案件では、GitHubのURLがプロフィールにあるだけで書類通過率が上がるという声も多い。

よくあるトラブルと解決法

コンフリクト（競合）

複数人が同じファイルの同じ行を変更した場合に発生する。慌てずに、以下の手順で解消する。

コンフリクトが発生したファイルを開く
<<<<<<<と>>>>>>>で囲まれた部分を確認
どちらの変更を残すか判断して手動で編集
編集後、addしてcommit

最初はコンフリクトが怖くて、マージするたびにドキドキしていた。でも慣れると、むしろ「ここ変更してたんだな」と気づけるので、ありがたい仕組みだとわかる。

間違えてcommitした

直前のコミットを取り消したい場合は：

git revert HEAD

revertは「打ち消しコミット」を新たに作成する安全な方法。git resetは履歴ごと消えるので、チーム開発では使わないほうがいい。

pushする前にpullし忘れた

git pull --rebase origin main

--rebaseオプションをつけると、リモートの変更の上に自分の変更を載せ直してくれる。マージコミットが増えずに履歴がきれいになる。

学習に使える無料リソース

GitHub公式のGit Handbook: 図解付きで基本概念を解説
Learn Git Branching: ブラウザ上でブランチ操作を視覚的に学べるインタラクティブ教材。ブランチの理解に最適
Progate Git講座: 日本語でハンズオン形式で学べる
サル先生のGit入門: 日本語の定番チュートリアル。初心者はここから

学習時間の目安は、基本操作が1〜2週間、ブランチ運用込みで1ヶ月程度。毎日30分で十分だ。

よくある質問

Q. GitHubの利用には料金がかかりますか？

基本的な機能はすべて無料で利用できます。以前はプライベートリポジトリ（非公開）の作成が有料でしたが、現在は個人開発であれば数に制限なく無料で作成可能です。フリーランスとしてクライアントのコードを管理する場合も、無料プランで十分対応できることがほとんどです。ただし、チームでの詳細な権限管理や高度なセキュリティ機能、自動化ツールの実行時間の拡張などが必要な場合は、有料プランを検討しましょう。

Q. 初心者はコマンド入力（CLI）と専用ソフト（GUI）のどちらを使うべきですか？

最初は「GitHub Desktop」などのGUIツールを使うと、変更履歴が視覚的にわかりやすいため挫折しにくいです。しかし、現場ではエンジニア同士のやり取りがコマンド（CLI）ベースで行われることが多く、細かい操作もコマンドの方が確実です。まずはGUIで「何が起きているか」を視覚的に理解し、慣れてきたらターミナルでの基本コマンド（add, commit, push, pull, status）を習得するのが効率的です。

Q. 間違えてファイルをコミットしたり、ネット上に公開（push）してしまったら？

ローカルでのコミットならコマンドで取り消せますが、一度GitHubに公開（push）したものは注意が必要です。履歴を消去する操作は可能ですが、他の人が既に取得（pull）していると混乱を招きます。特にAPIキーなどの機密情報を公開してしまった場合は、履歴を消すだけでなく、即座にキーを無効化してください。「.gitignore」を最初に設定し、機密ファイルを管理対象外にすることが最大の防御策です。

Q. フリーランス案件で、GitHubのアカウントをクライアントと共有する必要がありますか？

アカウントそのものを共有（パスワードの受け渡し）することは絶対NGです。通常は、クライアントが作成した組織（Organization）やリポジトリに、あなた個人のアカウントを「コラボレーター」として招待してもらう形で参加します。そのため、案件ごとにアカウントを使い分ける必要はなく、一つのアカウントで複数の現場を横断して作業できます。制作実績も蓄積されるため、自身の評価向上にも繋がります。