
Gitコマンド備忘録
- 日本語
- Git
git add (ステージングエリアに追加)
git add は、ファイルへの変更を次のコミットに含めるために 「ステージングエリア」 と呼ばれる場所へ追加するコマンドです。
https://git-scm.com/docs/git-add
コミットするファイルをステージングに追加します。
ファイルごとにコミットに含めることが出来ます。
使用例
特定のファイルを1つのステージングエリアに追加する場合
git add index.html
複数のファイルを追加する場合
git add index.html style.css
カレントディレクトリ以下の全ての変更をステージングエリアに追加する場合
git add .
git commit (変更を記録)
git commit は、ステージングエリアにある変更内容を、メッセージと共にローカルリポジトリに記録(保存)するコマンドです。
https://git-scm.com/docs/git-commit
「誰が」「いつ」「何のために」変更したのかを記録(保存)するために使用します。コードの意味を振り返る場合に便利です。
使用例
メッセージ付きコミットを行う場合
git commit -m "ログイン機能を追加"
エディタを開いて長文のコミットメッセージを書く場合
git commit
git commit 実行後は、git add コマンドでステージングエリアに追加した変更ファイルがリポジトリに記録されるため、ステージングエリアは空になります。
git tag (重要なポイントに目印を付与)
git tag は、特定のコミットに対して分かりやすい名前(タグ)を付与するためのコマンドです。主に、バージョンのリリースポイントなど、後から参照したい重要なコミットに対して行います。
特定のコミット履歴に対して「 v1.0 」のような永続的な名前(タグ)を付与します。
a1b2c3d のようなコミットハッシュでは覚えにくいため、「 v1.0 」のような人間が理解しやすい名前で重要な地点をマークするために使用します。
https://git-scm.com/docs/git-tag
使用例
現在の最新コミットに軽量タグ v1.0 を付与する場合
git tag v1.0
タグ付けした日付や作成者などの情報を含んだ「注釈付きタグ」を作成する場合
-a オプションは annotated(注釈付き) を意味し、 -m はメッセージを意味します。
git tag -a v1.0.0 -m "バージョン1.0.0のリリース"
特定の過去コミットにタグを付ける場合
git tag v0.9 a1b2c3d # a1b2c3dはコミットハッシュの先頭部分
作成したタグの一覧を表示する場合
git tag
タグのプッシュ
Gitのタグはデフォルトではリモートリポジトリ(GitHubやBacklog Gitなど)にプッシュされません。他のメンバーとタグを共有するには 明示的にプッシュ する必要があります。
特定のタグをリモートにプッシュする場合
git push origin <タグ名>
全てのタグを一度でリモートにプッシュする場合
git push --tags
タグの削除
誤って作成したタグや、不要になったタグは削除できます。
ローカルリポジトリからタグを削除する場合
git tag -d <タグ名>
リモートリポジトリからタグを削除する場合
:<タグ名> という構文を使用します。
git push origin :<タグ名>
git merge (変更履歴を統合)
git merge は、異なるブランチの変更履歴を 現在のブランチに統合 するコマンドです。複数の開発者が異なる機能を別ブランチで作業後に、それらの変更を一つのブランチにまとめる際によく使われます。
別のブランチやタグの変更内容を、現在のブランチに取り込むことが出来ます。
チームメンバーが異なる機能開発を並行して進めた後、その成果をメインのコードライン(例: main ブランチ)にまとめるために使います。
https://git-scm.com/docs/git-merge
使用例
git merge は、現在チェックアウトしているブランチに対して、指定したブランチやタグの変更を取り込みます。
ブランチからマージする場合
例えば、feature ブランチで新しい機能の開発が完了し、その変更を main ブランチに統合したい場合は、まず main ブランチにチェックアウトします。
git switch main
feature ブランチの変更内容を、現在チェックアウトしている main ブランチに対してマージします。
git merge feature
このコマンドを実行すると、 main ブランチの履歴に feature ブランチの履歴が統合されます。Gitは自動的に変更を統合しようとしますが、
同じファイルの同じ行が両方のブランチで変更されていた場合など、競合(コンフリクト)が発生することがあります。その際は、手動で競合を解決する必要があります。
タグからマージする場合
タグは特定のコミットを指すため、タグからのマージは「特定の時点の変更をマージする」ことを意味します。 これは、過去の特定バージョンに戻って、その状態から新しい作業を開始したい場合などに使われることがあります。
現在のブランチに対して、 v1.0.0 というタグが指すコミットの変更をマージする場合は以下のようになります。
git merge v1.0.0
この操作は、 git merge が内部的にコミットハッシュを参照しているため、タグ名でも機能します。
git status (リポジトリの状態を確認)
git status は、現在の作業ディレクトリとステージングエリア、そしてリポジトリの状態を表示するコマンドです。
開発中によく使用します。
どのファイルが変更されたか、どのファイルがステージングエリアに追加されたか、どのブランチにチェックアウトしているかなど、 現在の状況を把握 場合に使用することが多いです。
次にどんなコマンドを実行すべきか判断するために、現状を把握することが不可欠です。 git status でこまめに現状を把握することで、意図しない変更をコミットしてしまうのを防ぎます。
https://git-scm.com/docs/git-status
使用例
現在のリポジトリ状態を確認する場合
git status
すると、状態が表示されます。
Changes to be committed:: ステージング済みChanges not staged for commit:: ステージングされていない変更Untracked files:: 追跡されていない新規ファイル
git clone (リポジトリを複製)
git clone は、リモートリポジトリ(GitHubなどにある共有のプロジェクト)を、ローカルマシンに 完全に複製 するコマンドです。
共有リポジトリの全履歴(全コミット、全ブランチ)を自分のローカルマシンにダウンロードして、作業を開始出来るようにします。
チーム開発で既存プロジェクトに参加する場合、まず最初にこのコマンドを使ってコードベースを自分の環境に用意します。
https://git-scm.com/docs/git-clone
使用例
<リポジトリURL> のプロジェクトをローカルに複製する場合
git clone <リポジトリURL>
特定の名前のディレクトリに複製したい場合
git clone <リポジトリURL> <ディレクトリ名>
git push (変更をリモートへ送信)
git push は、ローカルリポジトリでのコミット内容を、GitHubなどの リモートリポジトリへ送信 するコマンドです。
これにより、自分の変更内容を他のチームメンバーと共有できます。
ローカルでの作業履歴を共有リポジトリにアップロードする際に使用します。
自分の成果をチームメンバーに共有し、プロジェクト全体の進捗に貢献するために使います。
https://git-scm.com/docs/git-push
使用例
現在のブランチに対するコミットをリモート(origin)にプッシュする場合
git push origin <ブランチ名>
初回プッシュ時など、追跡設定を同時に行う場合
git push --set-upstream origin <ブランチ名>
git pull (変更をリモートから取得)
git pull は、リモートリポジトリにある最新の変更内容を、自分の ローカルリポジトリに同期 させるコマンドです。
他のメンバーがプッシュした変更を取り込み、自分のローカル環境を最新の状態に保ちます。
チーム開発では、他のメンバーが常に変更をプッシュしています。自分の作業を開始する前や、コミットをプッシュする前に git pull を実行して最新の状態にしておくことが、競合(コンフリクト)を防ぐ上で非常に重要です。
https://git-scm.com/docs/git-pull
使用例
現在のブランチの最新の変更をリモート(origin)から取得する場合
git pull origin <ブランチ名>
おわりに
Gitのコマンドはたくさんあるため、自分が使う際に随時更新していこうと思います。