Git & GitLab 入門 (3) ～Git マスターへの道～「Git操作チーム利用コマンドやロールバック」

1 はじめに
2 チーム開発で行うことがある操作
3 コミットの戻し方
4 まとめ
5 参考文献

はじめに

Git & GitLab入門ブログ Gitマスターへの道の第3回です。前回のGit & GitLab入門ブログ2 Gitマスターへの道「Git操作入門」では、ローカルPCにGit、VSCodeを導入し、最初のコミットを行うまでの手順を解説しました。

今回は、チーム開発で使うコマンド、コミットを戻す際に使用するコマンドについて紹介します。

チーム開発で行うことがある操作

まずは前回説明したGit操作を踏まえて、実際のチーム開発でよく使うコマンド（操作）について活用例を交えて紹介していきます。

git log

Gitリポジトリのコミット履歴を表示するコマンドです。履歴を見るだけでなくオプションによってプロジェクトの過去の分析や問題の原因究明に役立てることができます。

チーム開発での活用例

バグ特定：特定の機能がいつ、誰によって導入されたか、どのコミットが原因でバグが発生したかを追跡
マージコンフリクトの原因究明：複雑なマージの前に履歴を確認することで、コンフリクトの発生源究明に役立つ

オプション

git log –oneline: 各コミットを1行で簡潔に表示します。
git log –graph –oneline –all: ブランチの分岐・結合をグラフィカルに表示し、全てのブランチの履歴を1行で表示します。
git log -p <ファイル名>: 特定のファイルの変更履歴と差分を表示します。
git log –author=”<著者名>”: 特定の著者が行ったコミットのみを表示します。
git log –grep=”<キーワード>”: コミットメッセージに特定のキーワードを含むコミットを検索します。

以下はGitリポジトリのコミット履歴を表示するgit logの使用例です。

git logの使用例

今回の例ではコミット履歴を新しい順に表示しています。

commit から始まる複数のブロックが、それぞれ過去に行われた変更（コミット）を表しています。mainブランチへのコミット日時やコメント、設定している場合は誰が行ったかなどが表示され、チーム全体での変更履歴の確認が可能です。

git diff

gitの差分を表示するためのコマンドです。

インデックスとワークツリーの差分(addしていない手元の変更点)やコミットとワークツリーの差分などを確認することができます。

チーム開発での活用例

コミット前の最終確認：コミットする前に、意図しない変更が含まれていないかを確認します。
コードレビュー：他のメンバーの変更内容をレビューする際に、差分を確認します。

以下の画像はまだステージングされていない、ワーキングツリー（作業ディレクトリ）での変更内容を表示するgit diffコマンドの使用例です。

git diffの使用例

git diff の出力を見ることで、コミットしようとしている変更が、どのファイルに、どの行が、どういった内容で追加・削除されたかを明確に把握することができます。

git tag

特定のコミットにタグをつけたり、タグの確認をするコマンドです。

タグを使用することでコミットを分かりやすく保管することができます。

チーム開発での活用例

重要なポイントの記録：v1.0.0, v2.1.0 のように、ソフトウェアのリリースバージョンにタグを付け、後からその時点のコードを簡単に参照できるようにします。
リリースバージョンの管理：特定の重要なマイルストーンや、大きな変更があったコミットにタグを付けて、履歴を分かりやすくします。

以下の画像は最新のコミットに対してタグを作成するgit tagの使用例です。

git tagの使用例

最新のコミットへ `v1.0-beta`というタグを作成することで、その後はgit show (タグ名) などのコマンドを使用することでコミット内容を簡単に確認出来るようになります。

.gitignore

.gitignoreはコマンドではなく、Gitリポジトリに配置されるファイルです。

.gitignoreにファイル名やディレクトリ名を記載することで、Gitの追跡対象からそれらを無視させることができます。ルートだけでなくサブディレクトリにも配置することができ、その場合、そのファイルが置かれたディレクトリとそのサブディレクトリにルールが適用されます。

チーム開発での活用例

リポジトリをきれいに保つ：不要なファイルやバージョン管理の対象にしたくないファイルやディレクトリがコミットされるのを防ぎ、リポジトリのサイズを小さく保ちます。
バージョン管理の対象にしたくないファイルとはコンパイル時やエディタが自動生成するファイル(dist/, build/)やライブラリ依存のファイル(node_modules/)、キャッシュファイル(__pycache__/, .pytest_cache/)などがあります。
環境変数、機密情報などGitから除外：公開リポジトリや誤って共有してしまった場合のセキュリティリスクを減らします。

以下画像は.gitignoreファイルの例です

.gitignoreの作成例

主にPythonでの開発時の不要ファイルを定義しています。

コミットの戻し方

チーム開発時では意図しない内容をコミットへ含めてしまったり、前の状態へ戻したいなどの状況が発生します。

そのような状況でもgitではコミットをコマンドで取り消すことができます。

状況によりコマンドの使い分けが必要です。

git revert

すでにリモートにpushしている場合 git revertを使います。

git revertは間違ったコミットを打ち消す新しいコミットを追加して取り消します。元のコミットは残ったままです。

以下画像はgit revertの使用例です。

コミットハッシュを使用してgit revertを使用する例

↑コミットをpushしたのちgit revertコマンド実行

git revert実行後の編集画面

↑git revertコマンド実行後のコミット内容編集画面

編集後再度pushする際の例

↑git revert後コミットを再度push

これによりgit revertを使用して打ち消したいコミットの内容を打ち消す内容のコミットがpushされます。

VScodeから実行する場合以下のようになります

git revertをVScodeから実行する例

git reset

コミット履歴自体を操作する強力なコマンドです。いくつかオプションがありますが、ここではよく使うものを簡単に紹介します。

git reset –soft [コミットID]: 指定したコミットの状態に戻しますが、ファイルの変更内容はそのまま残し、ステージングされた状態にします。
git reset –mixed [コミットID] (デフォルト): 指定したコミットの状態に戻し、ファイルの変更内容も残しますが、ステージングは解除されます。
git reset –hard [コミットID]: 指定したコミットの状態に戻し、指定したコミットIDの状態にプロジェクト全体を完全に巻き戻します。普段作業しているPC上のプロジェクトフォルダやステージングエリアもすべて破棄します。

この操作は非常に危険で、元に戻すことができないため、使用には細心の注意が必要です。

git resetは履歴そのものを書き換えて取り消しします。git resetでpush後のコミットを操作すると他のチームメンバーにも影響が有るため、非常に危険な操作だと意識しましょう。

以下の画像は直前のコミットを取り消しつつ、変更内容は残すgit reset –soft HEAD~1の使用例です

git reset –soft HEAD~1の使用例

VScodeから実行する場合以下のようなります

git resetをVScodeから実行する例

git restore

git restoreは、コミットされた履歴ではなく、ワークツリー（手元のファイル）やステージングエリア（git addした変更）の変更を元に戻すために使用するコマンドです。git resetよりも粒度が細かく、安全です。

以下はコマンドでのステージングエリアの変更取り消しの実行例です。

git restoreの使用例

VScodeで実行する場合以下のようになります

git restoreをVScodeで実行する例

まとめ

今回はチーム開発で使うコマンド、コミットを戻す際に使用するコマンドを紹介しました。これでGitを使ったチーム開発において、コードの変更管理と履歴の追跡をよりスムーズに行うことが出来るようになります。次回は、Gitを使った共同開発の基本として、リモートリポジトリの役割やクローン、SSH設定、そして変更を反映する一連の流れを詳しく解説します。