「修正前のファイルは、どこに保存したっけ？」

「最終版、最終版2、本当の最終版……結局どれが最新？」

こんな経験はありませんか。ファイルをコピーして残す方法でも、小さな作業なら対応できます。しかし、修正が増え、担当者が増えると、いつ何を変えたのかを追いかけるだけで時間がかかります。

そこで役立つのが、バージョン管理ツールのGit（ギット）です。

Gitを使うと、ファイルの変更を記録し、修正前後の違いを確認し、必要に応じて過去の内容を取り戻せます。一人でPHPを書いている場合にも、Linuxサーバーの設定や運用スクリプトを管理する場合にも使えます。

この記事では、Gitの概要からLinuxでの導入、日常的な操作、GitHub・GitLab・Bitbucketとの連携まで、手を動かしながら解説します。

Gitとは？「変更の履歴」を管理する道具

Gitは、ファイルがどのように変わったかを記録する、分散型のバージョン管理ツールです。「分散型」とは、手元のPCやサーバーにも履歴を持てる仕組みのことです。

例えば、問い合わせフォームのプログラムを修正したとします。

Gitには、変更した内容とともに、作成者として設定した名前・メールアドレスや日時、説明を残せます。ただし、作成者情報は設定値なので、それだけで本人確認ができるわけではありません。

大切なのは、「現在のファイル」だけでなく、「そこに至る変更の経緯」を残せることです。

Gitは導入しただけで変更を自動記録するわけではありません。後で説明する「コミット」という操作で、記録する区切りを自分で決めます。

なぜGitが必要なのか？現場で起きる4つの事例

以下は、Gitの使いどころを説明するための想定事例です。

事例1：PHPを修正したらログインできなくなった

ログイン画面の見た目を変更するつもりでPHPを修正したところ、認証まで動かなくなりました。

Gitを使っていないと、「どのファイルの、どの行を変更したか」を思い出すところから始まります。バックアップがあっても、そこから先に行った正常な修正まで消してしまうかもしれません。

Gitで変更を記録していれば、修正前後の差分を確認できます。問題の変更を見つけ、必要な範囲で取り消すこともできます。

ただし、Gitは原因を自動診断するツールではありません。差分や履歴を調査の材料として使い、動作確認と組み合わせます。

事例2：二人が同じファイルを編集した

Aさんが問い合わせフォームを修正し、Bさんが同じファイルに別の項目を追加しました。FTPで順番にアップロードすると、後からアップロードした内容で前の変更を上書きしてしまうことがあります。

Gitでは、それぞれの変更を取り込んでまとめる「マージ」ができます。同じ箇所を変更して自動で判断できない場合には、「競合」として人の確認を求めます。

自動でマージできても、組み合わせた結果が正しく動くとは限りません。変更内容のレビューとテストは必要です。

事例3：担当者が変わり、変更の理由が分からない

Linuxの運用スクリプトに、用途が分からない条件分岐がありました。削除してよいか判断できず、前任者への確認もできません。

履歴に「バックアップ先の容量不足時は処理を止める」と記録してあれば、その変更の目的を理解しやすくなります。

Gitの価値は、戻せることだけでなく、次の担当者に理由を残せることにもあります。

事例4：AIに修正を頼んだら、想定以上に書き換わった

AIに「このエラーだけ直して」と頼んだところ、別の処理まで書き換わることがあります。

修正前にコミットしておけば、AIによる変更を差分で確認できます。必要な変更かどうかを判断してから、次のコミットに残せます。

AIがコードを書くようになっても、「どこを変えたのか」を確認する仕事は残ります。Gitは、その確認を支える道具です。

GitとGitHubは別のもの

まず、混同しやすい言葉を整理しましょう。

Gitは手元で使う道具、GitHubなどはチームで共有する場所と機能と考えると分かりやすくなります。

Gitだけなら、アカウントを作らずに使い始められます。GitHubなどへの通信ができない状況でも、手元で履歴を確認したり、コミットしたりできます。

この記事では、連携先としてGitHub.com、GitLab.com、Bitbucket Cloudを扱います。

最初に覚える言葉は、この7つ

基本操作は、編集 → 記録する変更を選ぶ → 内容を確認 → コミットです。

GitHubなどへ共有するときは、その後に「push」を行います。コミットしただけでは、共有先には送られません。

LinuxにGitをインストールする

ここからは、ログイン中の一般ユーザーが所有するホームディレクトリで練習します。本番サイトのファイルを直接変更する必要はありません。

Git操作は通常のユーザーで行い、パッケージのインストール時だけsudoを使います。

Rocky Linux・AlmaLinux・RHEL系

sudo dnf install git openssh-clients

gitはバージョン管理ツール、openssh-clientsは後半で使うSSH接続や鍵作成のためのパッケージです。

Ubuntu・Debian系

sudo apt update
sudo apt install git openssh-client

apt updateでパッケージ一覧を更新し、GitとSSHクライアントをインストールします。

インストールを確認する

git --version

Gitのバージョンが表示されれば、インストールを確認できます。バージョン番号はOSや配布パッケージによって異なります。

この記事のgit switchとgit restoreはGit 2.23以降を前提にしています。古い環境では、OSでサポートされる更新方法を確認してください。

参考：Git公式・Linuxへのインストール

名前とメールアドレスを設定する

コミットに記録する情報を設定します。以下の名前とメールアドレスは自分のものに置き換えてください。

git config --global user.name "Taro Yamada"
git config --global user.email "taro@example.com"

--globalは、現在のLinuxユーザーが使うGitの共通設定にする指定です。他のLinuxユーザーには適用されません。

確認します。

git config --global --get user.name
git config --global --get user.email

これはGitHubなどへのログイン設定ではありません。コミットの作成者情報です。公開するリポジトリでは、このメールアドレスが履歴から見える点にも注意してください。GitHubではアカウントのメール設定で確認できる非公開用アドレスを使う方法もあります。

会社のプロジェクトだけ別の情報にする場合は、そのリポジトリ内で--globalを付けずに設定します。

git config user.name "Taro Yamada"
git config user.email "taro@company.example.com"

練習用のリポジトリを作る

ホームディレクトリに練習用フォルダーを作ります。

mkdir -p ~/git-practice/example-site
cd ~/git-practice/example-site
git init
git branch -M main

git initを実行すると、.gitという管理用ディレクトリが作られます。この中に履歴などが保存されるため、削除しないようにします。

HTMLファイルを作成する

cat > index.html <<'EOF'
<!doctype html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>Git練習サイト</title>
</head>
<body>
  <h1>Gitの練習を始めます</h1>
</body>
</html>
EOF

cat > ファイル名は、続く内容をファイルに書き込む操作です。同名のファイルがあると上書きされるので、この練習用フォルダーで実行します。

続けて、プロジェクトの説明を作ります。

cat > README.md <<'EOF'
# Git練習サイト

LinuxでGitの基本操作を学ぶためのサンプルです。
EOF

README.mdは、目的や使い方を記載するファイルです。GitHubなどでも、プロジェクトの説明として表示できます。

管理しないファイルを.gitignoreで指定する

すべてのファイルをGitへ入れる必要はありません。パスワードなどが入る環境設定、ログ、一時ファイルなどは、管理対象から除外します。

cat > .gitignore <<'EOF'
.env
.env.*
!.env.example
*.log
*.pem
*.key
/node_modules/
/vendor/
/backups/
EOF

この例では、.envや.env.productionを除外し、設定例として使う.env.exampleは例外にしています。.env.exampleにも本物のパスワードやAPIキーは入れません。

*.pemと*.keyは、この入門例で鍵ファイルを誤登録しにくくする指定です。PEM形式には公開証明書もあるため、実際のプロジェクトでは用途に合わせて調整してください。

vendorやnode_modulesを除外する場合でも、依存関係を再現するためのcomposer.lockやpackage-lock.jsonなどは、プロジェクトの方針に沿って管理します。

.gitignoreは、すでにGitで追跡されているファイルには効きません。 また、秘密情報を一度コミットした後でファイルを削除しても、過去の履歴には残ります。漏えいした鍵やパスワードの無効化・再発行と、履歴への対応が必要になります。

参考：Git公式・gitignore

最初のコミットをする

まず、現在の状態を確認します。

git status

新しく作ったファイルは、まだ追跡されていないファイルとして表示されます。次に、記録するファイルを指定します。

git add index.html README.md .gitignore
git diff --cached

git addは、指定したファイルの現在の内容をステージングします。git diff --cachedで、コミットに含まれる変更を確認します。

問題がなければ、コミットします。

git commit -m "練習サイトの初期ファイルを追加"
git status

-mの後ろは、変更の説明です。「修正」「更新」だけでなく、「何をしたか」を残すと、後から役立ちます。

ここまでで、手元に最初の履歴ができました。まだGitHubなどには送っていません。

参考：Git公式・git commit

ファイルを変更し、差分と履歴を確認する

見出しを書き換えてみます。

sed -i 's/Gitの練習を始めます/Gitで変更履歴を管理します/' index.html
git diff

sed -iは、指定した文字列をファイル内で置き換えます。ここではLinuxのsedを使っています。

git diffでは、通常、削除された行が-、追加された行が+で示されます。同じ行を書き換えた場合も、変更前の行と変更後の行として表示されます。

確認して記録します。

git add index.html
git diff --cached
git commit -m "トップページの見出しを変更"
git log --oneline

git log --onelineは、履歴を一行ずつ表示するコマンドです。先頭の英数字がコミットを識別するID、後ろが説明です。

直近のコミットで何を変更したかを見る場合は、次を使います。

git show HEAD

HEADは、通常、現在のブランチの最新コミットを指します。

git diffとgit diff –cachedの違い

git addした後にもう一度編集した場合、その追加の編集はまだステージングされていません。コミットに含めるには、再びgit addします。

また、新規の未追跡ファイルは通常のgit diffに出ません。git statusも合わせて確認しましょう。

「戻す」は、状況に応じて使い分ける

Gitで戻せるのは、基本的に記録した内容です。コミットしていない作業を捨てると、その編集をGitから復元できるとは限りません。

まだステージングしていない変更を取り消す

例えば、先ほどのindex.htmlを編集したものの、その編集を取り消したい場合です。

git diff -- index.html
git restore -- index.html

先に差分を確認してから実行します。git restoreは、通常、ステージング済みの内容に作業ファイルを戻します。ステージングしていなければ、最後にコミットした内容と一致します。

この操作では、対象ファイルの未記録の編集が失われます。 残したい内容がある場合は実行しません。

git addの選択だけを取り消す

git restore --staged -- index.html

この例は、最初のコミットがあるリポジトリで使います。ステージングを取り消しますが、作業ファイルの編集内容は残ります。

参考：Git公式・git restore

コミット済みの変更を取り消す

共有済みの変更を取り消す場合は、「取り消したという新しい記録」を作るgit revertが役立ちます。

git status
git log --oneline

作業中の変更がないことを確認し、取り消したいコミットのIDを調べます。次のCOMMIT_IDを実際のIDに置き換えて実行します。

git revert --no-edit COMMIT_ID

元のコミットを消すのではなく、その変更を打ち消す新しいコミットを作ります。後の変更とぶつかる場合は、競合の解消が必要です。マージコミットを取り消す場合は追加の指定と検討が必要なので、この入門例とは分けて扱ってください。

参考：Git公式・git revert

ブランチで、作業の流れを分ける

新機能を試すとき、すぐに通常のコードへ混ぜたくない場合があります。そこでブランチを使います。

ここでは、mainを通常の変更をまとめるブランチとし、お知らせページを追加する作業を分けます。

git status
git switch -c feature/news-page

作業中の変更がない状態で始めます。-cは、新しいブランチを作成して切り替える指定です。

cat > news.html <<'EOF'
<!doctype html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>お知らせ</title>
</head>
<body>
  <h1>お知らせ</h1>
  <p>Gitの練習サイトを公開しました。</p>
</body>
</html>
EOF

git add news.html
git diff --cached
git commit -m "お知らせページを追加"

元のブランチへ戻ります。

git switch main
ls

mainにはまだ追加していないため、通常、この時点ではnews.htmlが作業フォルダーからなくなります。

ブランチは、作業フォルダーを別の場所に複製する操作ではありません。切り替えると、同じフォルダー内のファイルが、そのブランチの内容に合わせて変わります。

動作を確認する場合はfeature/news-pageに切り替え、内容を確認したらmainへ戻して取り込みます。

git switch feature/news-page
# ファイルの内容や表示を確認する
git switch main
git merge feature/news-page
git log --oneline --graph --all

この練習ではローカルでマージします。チーム開発では、後半のプルリクエスト／マージリクエストを経由して取り込む運用もできます。

参考：Git公式・git switch、Git公式・git merge

GitHub・GitLab・Bitbucketの違いを詳しく知る

どのサービスを使っても、基本のadd、commit、pushなどはGitのコマンドです。違うのは、共有先の機能や開発の進め方です。

GitHub：コード共有とレビュー、自動化を組み合わせる

GitHubでは、リポジトリを作り、コードや履歴をブラウザーで確認できます。

変更の提案にはPull Request（プルリクエスト）を使います。「この変更をmainに取り込んでよいですか」と提案し、差分を見ながらコメントやレビューを行う仕組みです。

不具合や作業項目を整理するIssuesも使えます。修正の提案と作業項目を関連付けると、「どの問題を直した変更か」を追いやすくなります。

GitHub Actionsでは、コードを送った際のテストや、承認された変更の公開などを自動化できます。処理は.github/workflows/配下のYAMLファイルで定義します。

本記事で最初に試す共有先としてGitHubを使うのは、リポジトリの作成、変更の共有、レビューまでを一つの流れで学べるためです。会社で指定のサービスがある場合は、それに合わせれば問題ありません。

参考：プルリクエスト、Issuesとの関連付け、GitHub Actions

GitLab：コード管理からテスト・公開までをまとめる

GitLabでは、変更の提案をMerge Request（マージリクエスト）と呼びます。GitHubのプルリクエストと同様に、変更内容を確認して取り込むための機能です。

GitLab CI/CDでは、.gitlab-ci.ymlに処理を定義し、テスト、ビルド、公開などを実行できます。処理を実際に動かす実行環境をRunnerと呼びます。

GitLab.comを利用する方法に加え、GitLab Self-Managedとして自社側で運用する方法もあります。コードや開発基盤を自社で管理したい場合の選択肢になりますが、サーバー構築、更新、バックアップ、監視などの運用も必要です。

参考：マージリクエスト、GitLab CI/CD

Bitbucket：Jiraで管理する仕事とコード変更をつなげる

BitbucketはAtlassianのGit管理サービス／製品です。本記事で扱うBitbucket Cloudでは、リポジトリ共有、プルリクエストによるレビュー、Bitbucket Pipelinesによる自動処理を利用できます。

Pipelinesの設定はbitbucket-pipelines.ymlで行います。

特徴の一つは、Atlassianの課題管理ツールJiraとの連携です。Jiraの課題とブランチ、コミット、プルリクエストを関連付けることで、作業の依頼とコード変更を追いやすくなります。Jiraを中心に開発を進めているチームでは、検討しやすい選択肢です。

参考：Bitbucketの概要、Bitbucket Pipelines

3サービスを比較する

機能の利用条件、実行時間、保存容量、承認ルールなどはプランによって異なります。料金や上限は変わるため、利用開始時に各社の公式情報を確認してください。

なお、CIは、変更を取り込む際にテストなどを継続的に実行する仕組みです。CDは、リリース可能な状態を維持したり、公開まで自動化したりする仕組みを指します。

Gitに変更を送るだけで、自動的に本番サイトが更新されるわけではありません。公開処理は別途設定します。

LinuxからSSHで接続する準備

GitHubなどへの接続にはHTTPSとSSHがあります。ここでは、3サービスで共通して使えるSSHを例にします。

公開鍵と秘密鍵とは？

既存の鍵を確認してから作成する

ls -al ~/.ssh

ディレクトリがないという表示なら、まだ作成されていない可能性があります。既存の鍵を上書きしないよう、この記事では専用の名前を使います。

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519 -C "taro@example.com" -f ~/.ssh/id_ed25519_git_services

同名のファイルがある場合、上書きを承認せず、別名にしてください。作成時には、秘密鍵を保護するパスフレーズの入力を求められます。

作成した鍵をSSHエージェントに登録します。

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_git_services
cat ~/.ssh/id_ed25519_git_services.pub

最後のコマンドで表示される公開鍵をサービスへ登録します。.pubの付いていない秘密鍵はコピーしません。ログインし直した際には、環境によってエージェントへの再登録が必要です。

以下は一台・一アカウントずつ使う入門例です。複数の業務アカウントを使う場合は、鍵とSSH設定を分ける運用を検討します。

参考：GitHub公式・SSH鍵の作成

GitHubへ初めて送る

手順1：公開鍵を登録する

GitHubにログインし、アカウント設定のSSH and GPG keysからSSH鍵を追加します。タイトルには「Rocky Linux 開発環境」など、どの環境の鍵か分かる名前を付けます。

登録するのは、前の手順で表示した公開鍵です。用途の選択がある場合は、接続認証用の鍵として登録します。

手順2：接続を確認する

ssh -T git@github.com

初回接続でホスト鍵の確認が出たら、表示されたフィンガープリントを公式情報と照合してから承認します。

GitHubでは、認証成功とシェル接続を提供しない旨が表示されます。SSH認証に成功しても、この確認コマンドの終了コードは1になります。

参考：GitHubのホスト鍵情報

手順3：空のリポジトリを作る

GitHubで新しいリポジトリを作成し、名前をexample-siteにします。

今回は手元にファイルと履歴があるため、GitHub側ではREADME、.gitignore、ライセンスの追加を選ばず、空のリポジトリを作成します。公開範囲は、練習ならPrivateを選んで進められます。

手順4：共有先を登録し、pushする

次のYOUR_USERを自分のGitHubユーザー名に置き換えます。URLは作成したリポジトリの画面に表示されるSSH URLを使うのが確実です。

cd ~/git-practice/example-site
git remote add origin git@github.com:YOUR_USER/example-site.git
git remote -v
git push -u origin main

GitHubのリポジトリ画面を開き、ファイルとコミットが表示されることを確認します。

以後、変更をコミットした後は、同じブランチなら通常git pushで送れます。

参考：GitHub公式・ローカルのコードを追加する

GitLabとBitbucketで使う場合

Gitの基本操作は同じです。アカウントへの公開鍵登録、リポジトリ作成、接続先の指定が変わります。

GitLab.comの場合

1. GitLabにログインする。
2. プロフィールの編集／ユーザー設定からSSH Keysを開き、公開鍵を登録する。
3. 新規の空プロジェクトexample-siteを作成する。
4. READMEによる初期化を選ばず、公開範囲と名前空間を確認する。
5. プロジェクト画面のSSH URLをコピーする。

接続確認は次のとおりです。初回のホスト鍵はGitLab公式情報と照合します。

ssh -T git@gitlab.com

まだoriginを登録していないリポジトリでは、次を実行します。YOUR_NAMESPACEは自分のユーザー名またはグループのパスに置き換えます。

git remote add origin git@gitlab.com:YOUR_NAMESPACE/example-site.git
git push -u origin main

Self-Managed環境では、ホスト名、SSHポート、利用できる鍵の種類などを管理者に確認してください。

参考：GitLab公式・SSH鍵、GitLab公式・リポジトリ

Bitbucket Cloudの場合

1. Bitbucketにログインする。
2. Personal Bitbucket settingsのSSH keysから公開鍵を登録する。
3. 利用するWorkspaceにexample-siteというリポジトリを作成する。
4. READMEを追加せず、空のリポジトリにする。
5. リポジトリ画面のSSH URLをコピーする。

接続確認は次のとおりです。初回のホスト鍵はAtlassian公式情報と照合します。

ssh -T git@bitbucket.org

まだoriginを登録していないリポジトリでは、次を実行します。YOUR_WORKSPACEは実際のWorkspaceのIDに置き換えます。

git remote add origin git@bitbucket.org:YOUR_WORKSPACE/example-site.git
git push -u origin main

ここでは個人のSSH鍵を使います。リポジトリのAccess keysは読み取り用途なので、pushするための個人鍵登録とは区別してください。

参考：Bitbucket公式・Linuxでの個人SSH鍵設定、接続とAccess keys

すでにGitHubをoriginとして登録した場合

上記は3サービスのどれかを選ぶ例であり、同じリポジトリでoriginを繰り返し追加する手順ではありません。

共有先を変更する場合は、git remote -vで確認したうえでgit remote set-url origin 新しいSSH_URLを使います。移行先にも履歴がある場合は、単純な送信ではなく、履歴と移行手順の確認が必要です。

別のLinux環境で続きを作業する

既存の共有リポジトリを手元に取得する操作がcloneです。

別のLinux環境でもGitの導入、名前・メールの設定、SSH認証を準備し、その環境専用の公開鍵をアカウントに登録します。

mkdir -p ~/projects
cd ~/projects
git clone git@github.com:YOUR_USER/example-site.git
cd example-site
git status

cloneでは、ファイルと履歴を取得し、通常はoriginも自動設定されます。取得したフォルダーでもう一度git initする必要はありません。

共有先の更新を取り込むには、作業中の変更がない状態で次を使います。

git switch main
git pull --ff-only

--ff-onlyは、履歴をそのまま進められる場合にだけ取り込む指定です。手元と共有先の両方で別々のコミットが増えている場合は、勝手にまとめずに止まります。

止まったときは、履歴を確認してマージやリベースを検討します。初心者のうちは、理由が分からないまま強制pushしないことが大切です。

参考：Git公式・git pull

チームで使う基本の流れ

チームでは、「mainから作業用ブランチを作り、変更を提案してから取り込む」という進め方ができます。

git switch main
git pull --ff-only
git switch -c fix/top-page-title

index.htmlのタイトルを変更します。

sed -i 's/<title>Git練習サイト<\/title>/<title>Git変更履歴の練習サイト<\/title>/' index.html
git diff
git add index.html
git diff --cached
git commit -m "トップページのタイトルを分かりやすく変更"
git push -u origin fix/top-page-title

ここで共有先の画面を開きます。

説明には「何を変えたか」「なぜ変えたか」「どう確認したか」を記載します。例えば、「ブラウザーのタブで用途が分かるようにタイトルを変更。表示と文字コードを確認」と書けば、確認する側も判断しやすくなります。

レビューや必要なテストが終わったら、画面上でマージします。承認人数やmainへの直接pushを制限する設定は、サービスとプラン、チームの方針に合わせて決めます。

手元のmainにも、マージ後の変更を取り込みます。

git switch main
git pull --ff-only

競合が起きたらどうする？

同じ箇所を別々に編集し、Gitがどちらを採用するか判断できないと、マージ時に競合が起きます。

例えば、ファイルに次のような目印が入ります。

<<<<<<< HEAD
<h1>社内向けのお知らせ</h1>
=======
<h1>お客様向けのお知らせ</h1>
>>>>>>> feature/change-heading

この目印は、完成したHTMLではありません。両方の変更の意図を確認し、最終的に必要な内容へ編集して、目印を削除します。

ローカルのgit mergeで起きた競合を直す場合は、次のように進めます。

git status
# 対象ファイルを編集し、内容と動作を確認する
git add index.html
git diff --cached
git commit -m "見出しの競合を解消"

まだマージを完了しておらず、今回のマージを中止する場合はgit merge --abortを使います。マージ前から未記録の変更があると元の状態への復元が難しくなる場合があるため、最初に作業をコミットするなどしてから始めます。

ここで説明しているのはマージの競合です。リベース中の競合は、続行や中止のコマンドが異なります。

Linuxの現場で管理すると便利なもの

Gitは、Webアプリのソースコード以外にも使えます。

サーバー設定を管理する場合も、まず作業用リポジトリにテンプレートを用意して確認し、別の手順で適用する方法が取れます。/etc全体をそのまま登録すると、認証情報などまで含める可能性があります。

本番サーバーでは、Gitのマージと公開を別の作業として考えます。PHPなら依存パッケージの導入、LaravelならキャッシュやDB変更、設定ファイルなら構文確認など、必要な処理はアプリごとに異なります。

導入時に押さえておきたいこと

データベースやアップロード画像は別にバックアップする

Gitでソースコードを管理しても、MySQLのデータや利用者がアップロードした画像まで自動で保存されるわけではありません。必要なデータのバックアップと復旧手順は、別途用意します。

.gitをWebから読める状態にしない

Webサーバーの公開ディレクトリに.gitが置かれていると、設定によっては履歴やコードが外部へ漏れる可能性があります。公開ディレクトリの外で管理し、公開に必要なファイルだけ配置する方法や、Webサーバー側でのアクセス制限を検討します。

変更は「説明できる単位」で記録する

フォーム修正、デザイン変更、バックアップ処理変更を一つにまとめると、後から特定の変更を取り消しにくくなります。

一方で、意味のない細切れにする必要もありません。「このコミットは何をしたものか」を一文で説明できる区切りを意識すると、履歴が読みやすくなります。

pushに失敗したら、まず原因を確認する

「送れないから--forceを付ける」という対応は、共有先の履歴を上書きするおそれがあります。エラーの理由を確認してから進めましょう。

よく使うコマンド早見表

最初は、一つのフォルダーから始めればよい

Gitのコマンドを最初から全部覚える必要はありません。まずは練習用フォルダーで、status、diff、add、commit、logを使ってみてください。

変更を確認し、理由を付けて記録する。それだけでも、「修正前はどうなっていたか」が分かるようになります。

次にGitHubなどへ共有し、ブランチとレビューを取り入れれば、複数人での作業にもつなげられます。

小さな修正ほど、「これくらいなら大丈夫」と記録を省きがちです。その小さな変更が原因で困ったとき、履歴があるかどうかで調査の始めやすさが変わります。次の修正から、変更の理由も一緒に残してみましょう。