Gitを導入するメリットとは？構築方法とフルスタック開発にGitHubがおすすめな理由
目次
なぜフルスタック開発にGitが必要なのか？
フルスタックでWebサイトを構築していると、フロントエンドの画面だけではなく、APIやデーターベース、認証、デプロイの設定など多くのファイルを編集することになります。
ファイルが増えてくると「どこを変更したのか分からない」「修正したら動かなくなった」「昨日の状態に戻したい」といった問題が起きることがあります。
そんなときに役立つのが Git です。
Gitはコードの変更履歴を残すためのバージョン管理ツールですが、GitHubと組み合わせることでバックアップや複数人での開発、さらにはデプロイの自動化まで行うことができます。
今回はGitを導入するメリットや構築方法、そしてフルスタックのサイトを作るならGitHubがおすすめなのか、僕が実際に開発するときの流れに当てはめて紹介していきます。
Gitとは？
Gitはファイルの変更履歴を記録するための 分散型バージョン管理システム です。
少し難しく聞こえますが、簡単にいえばコードの状態を好きなタイミングで保存して、必要になったら過去の状態を確認したり戻したりできる仕組みです。
Gitでは、この保存ポイントを コミット と呼びます。
ゲームで例えるならセーブデータのようなもので、機能を追加する前にコミットしておけば、実装に失敗しても正常に動いていた状態との差分を確認することができます。
ただし、Gitは自動的にすべてを保存してくれるツールではありません。自分で変更したファイルを選び、コミットして初めて履歴として残ります。
Gitを導入するメリット
変更した内容が分かる
Gitを使うと、どのファイルのどの行を追加・変更・削除したのかを確認できます。
Webサイトを構築していると、ほんの1文字の修正が原因で画面が表示されなくなることもあります。変更箇所が分かれば、すべてのコードを読み直さなくても問題の原因を探しやすくなります。
特にフルスタック開発ではフロントエンドとバックエンドの両方を編集するため、変更履歴が残っているだけでもデバッグの負担をかなり減らすことができます。
正常に動いていた状態へ戻せる
新しい機能を追加したものの、別の機能が動かなくなってしまうことはよくあります。
Gitでこまめにコミットしておけば、問題が起きる前のコードを確認できますし、必要であれば以前の状態へ戻すこともできます。
今まではファルダを丸ごとコピーして日付をつけて管理してた人も多いと思いますが、逆にフォルダが増えてしまってどこまで作業したか把握できなかったという経験ないでしょうか。
Gitを導入すれば、フォルダを何個も複製しなくても履歴の中でバージョンを管理できます。
新しい機能を安全に試せる
Gitには ブランチ という仕組みがあります。
ブランチは現在のコードから作業を枝分かれさせる機能です。公開中の安定したコードを残したまま、別のブランチで新しい機能を試すことができます。
実装が完成したらメインのブランチに統合し、失敗したら作業したブランチを使わなければいいため、修正や検証が簡単です。
複数人でもコードを共有できる
Gitは自分一人の開発でも役立ちますが、複数人で開発するとさらに力を発揮します。
誰がどのような目的で変更したのかをコミット単位で確認でき、別々のブランチで作業することで同じコードを直接上書きするリスクも減らせます。
もちろん同じ場所を同時に編集すると コンフリクト という競合が起きることはありますが、Gitが勝手にどちらかを消すのではなく、どちらの変更を採用するか確認できます。
デプロイを自動化できる
GitHubやCloudflare Workersなどのサービスと連携すると、Gitのリポジトリへコードをプッシュしたタイミングでビルドやテスト、デプロイを自動的に実行できます。
従来のようにFTPでファイルを一つずつアップロードする必要がなくなり、公開漏れや古いファイルをアップしてしまうミスも防ぎやすくなります。
コードを保存するために導入したGitが、そのまま 公開作業の自動化 にもつながるのは大きなメリットです。
Gitの構築方法
ここからは、すでにローカル環境にWebサイトのプロジェクトがあることを想定してGitを導入していきます。
Gitをインストールする
Windowsの場合は Git for Windows、macOSの場合はHomebrewなどを使ってGitをインストールします。
インストールが完了したら、ターミナルで次のコマンドを実行します。
git --versionGitのバージョンが表示されればインストールは完了です。
ユーザー名とメールアドレスを設定する
Gitのコミットには、誰が変更したのかという情報が記録されます。そのため最初にユーザー名とメールアドレスを設定します。
git config --global user.name "ユーザー名"
git config --global user.email "メールアドレス"GitHubを使う場合は、GitHubに登録しているメールアドレスを設定する方法があります。メールアドレスを公開したくない場合は、GitHubが用意している非公開用のメールアドレスも利用できます。
さらに、最初に作られるブランチ名を main に統一しておくとGitHubとの連携が分かりやすくなります。
git config --global init.defaultBranch mainプロジェクトをGitの管理対象にする
ターミナルでWebサイトのプロジェクトへ移動し、次のコマンドを実行します。
git initこれでプロジェクト内に .git という管理用のフォルダが作成され、Gitで変更履歴を管理できるようになります。
現在の状態は次のコマンドで確認できます。
git statusGitを使っていると何度も実行するコマンドです。分からなくなったら、まず git status で状態を確認する癖をつけると安心です。
.gitignoreを作成する
フルスタックのプロジェクトでは、Gitで管理してはいけないファイルがあります。
例えばNode.jsの node_modules、ビルド後のファイル、環境変数を保存する .env などです。
これらをコミットしないように、プロジェクトの直下へ .gitignore を作成します。
node_modules/
.env
.env.*
dist/
build/
.DS_Store特に .env にはデーターベースの接続情報やAPIキーなどが入ることがあります。公開リポジトリへプッシュすると第三者に見られてしまうため、GitHubへ送る前に必ず確認しておきたい部分です。
一度コミットした機密情報は、あとからファイルを削除しても過去の履歴に残る可能性があります。誤って公開した場合は、ファイルを消すだけではなくAPIキーやパスワードの再発行も必要になります。
最初のコミットを作成する
管理するファイルをステージへ追加し、最初のコミットを作成します。
git add .
git commit -m "Initial commit"git add . は現在のフォルダ内にある変更をまとめてステージへ追加するコマンドです。
便利な反面、不要なファイルや機密情報まで追加する可能性があります。コミットする前に git status や git diff --staged で内容を確認することをおすすめします。
GitHubと連携する方法
Gitだけでもローカル環境で変更履歴を管理できますが、パソコンが故障するとリポジトリごと失う可能性があります。
そこで、クラウド上にGitのリポジトリを保存できる GitHub と連携します。
GitHubにリポジトリを作成する
GitHubへログインして「New repository」から新しいリポジトリを作成します。
リポジトリは誰でも見られるPublicと、許可した人だけが見られるPrivateを選べます。サイトのソースコードや設定を公開する予定がなければ、まずはPrivateで作成しても問題ありません。
すでにローカル側でファイルや最初のコミットを作成している場合は、GitHub側のREADMEや.gitignoreを追加せず、空のリポジトリとして作成すると連携がシンプルです。
ローカルのリポジトリをGitHubへ送る
GitHubでリポジトリを作成するとURLが表示されます。そのURLをローカルのリポジトリに登録します。
git remote add origin https://github.com/ユーザー名/リポジトリ名.git
git push -u origin mainこれでローカルにあるコードと変更履歴がGitHubへ送られます。
2回目以降は、変更をコミットしてから次のコマンドで送ることができます。
git pushなお、GitHubではGit操作の認証にアカウントのパスワードをそのまま使うことはできません。HTTPSならブラウザ認証やPersonal Access Token、またはSSHキーなどを使って認証します。
普段の開発で使う基本的な流れ
Gitはコマンドの種類が多いのですが、最初からすべてを覚える必要はありません。
一人でサイトを構築する場合は、まず次の流れを覚えるだけでも十分に使い始めることができます。
- git status で変更を確認する
- git diff で変更内容を確認する
- git add でコミットするファイルを選ぶ
- git commit で変更履歴を保存する
- git push でGitHubへ送る
git status
git diff
git add src/routes/contact.tsx
git commit -m "お問い合わせフォームを追加"
git pushコミットメッセージは「修正」のような短い言葉だけではなく、何を変更したのか分かる内容にしておくと、あとから履歴を見たときに役立ちます。
僕の場合は、機能を一つ追加したときや正常に動く状態まで修正できたときなど、意味のあるまとまりでコミットするようにしています。
フルスタックのサイトを作るならGitHubがおすすめ？
結論からいうと、個人でフルスタックのサイトを構築する場合でも GitHubはおすすめ です。
単なるコードの保管場所ではなく、開発から公開までの流れを一つのリポジトリを中心に管理できるためです。
フロントエンドとバックエンドをまとめて管理できる
React RouterやNext.jsなどのフルスタックフレームワークでは、画面を表示するコードとサーバー側で動くコードが同じプロジェクトに入ることがあります。
GitHubのリポジトリにまとめておけば、画面の変更とAPIの変更を同じコミットで管理できます。
「フロントエンドだけ新しくなってAPIが古い」といったバージョンのズレが起きにくくなるため、フルスタックの構成と相性がいいと思います。
プルリクエストで公開前に確認できる
GitHubには Pull Request（プルリクエスト） という機能があります。
作業用のブランチからmainブランチへ変更を統合する前に、差分を一覧で確認したり、コードにコメントを付けたりできます。
複数人でのコードレビューに使う機能というイメージがありますが、一人で開発するときにも公開前のセルフチェックとして役立ちます。
GitHub Actionsでテストやデプロイを自動化できる
GitHubには GitHub Actions という自動化の仕組みがあります。
例えばmainブランチへコードがプッシュされたら、TypeScriptの型チェックやテストを行い、問題がなければ本番環境へデプロイするという流れを作れます。
Cloudflare WorkersにもGitHubのリポジトリと連携して、プッシュ時にビルドとデプロイを行う仕組みがあります。
僕のように一人で開発していると、チェックから公開までを毎回手作業で行うのは地味に手間がかかります。自動化しておけば同じ手順で公開されるため、作業の効率化だけではなくミスの防止にもつながります。
GitHubを使うときの注意点
GitHubは便利ですが、リポジトリへ送ってはいけない情報もあります。
- APIキー
- データーベースの接続情報
- JWTなどの署名に使うシークレット
- 管理画面のパスワード
- ユーザーの個人情報や本番データ
これらはPrivateリポジトリであってもコードへ直接書かず、GitHub ActionsのSecretsやCloudflareの環境変数など、専用の仕組みで管理することが大切です。
また、GitHubはバックアップ先として役立ちますが、データーベースの中身やアップロードされた画像まで自動的に保存してくれるわけではありません。
GitHubで管理するソースコードと、本番環境のデータを守るバックアップは分けて考える必要があります。
まとめ
Gitはコードの変更履歴を管理するためのツールです。
最初はコマンドやブランチの考え方が難しく、エラーが表示されると何をすればいいのか分からなくなることもあります。
僕もGitを使い始めたころは、コミットとプッシュの違いすら曖昧でした。しかし、まずは status、add、commit、push の流れだけに絞って使うと、少しずつ仕組みが分かるようになります。
フルスタックの開発では変更する範囲が広くなるため、正常に動いているコードを履歴として残せるだけでも大きな安心感があります。
さらにGitHubと連携すれば、コードの保管、レビュー、テスト、デプロイまでを一つの流れにすることができます。
これからフルスタックのサイト構築に挑戦する方は、プロジェクトを作った段階からGitを導入し、GitHubと連携することをおすすめします。