Close

git commit

git commit コマンドはプロジェクトで現在ステージされている変更のスナップショットをキャプチャします。コミット済みのスナップショットはプロジェクトの「安全」なバージョンだと考えられます。Git では明示的に指示されない限り、これらのスナップショットを変更することはありません。git commit を実行する前に、git add コマンドを使ってコミットに保存されるプロジェクトに変更をプロモート、または「ステージ」します。git commitgit add の 2 つは、最も使用頻度が高いコマンドです。


Git コミットと SVN コミット


どちらにも「コミット」が付いていながら、git commitsvn commit はまったくの別物です。svn を使ったことのある Git 初心者にとっては「コミット」という単語が混乱の元になりますので、それぞれの違いを詳しく見ていくことが重要です。git commitsvn commit を比較するということは、集中型アプリケーション モデル (svn) と分散型アプリケーション モデル (Git) を比較するということです。SVN では、コミットによってローカルの SVN クライアントからリモートの集中型共有 SVN リポジトリに変更がプッシュされます。Git ではリポジトリが分散されており、スナップショットはローカル リポジトリにコミットされるため、他の Git リポジトリを操作する必要はまったくありません。Git のコミットはその後、任意のリモート リポジトリにプッシュできます。

仕組み


より俯瞰的に見ると、Git はタイムライン管理ユーティリティとしても捉えられます。コミットは Git プロジェクトのタイムラインの中核を成す構成要素です。コミットは Git プロジェクトのタイムライン上のスナップショットまたはマイルストーンとしても考えられます。git commit コマンドでコミットを作成して、その時点のプロジェクトの状態をキャプチャします。Git スナップショットは、常にローカル リポジトリにコミットされます。これが SVN とは根本的に異なる点です。SVN では作業コピーが中央のリポジトリにコミットされます。対照的に、Git では準備が整うまで中央のリポジトリは操作不要です。ステージング エリアが作業ディレクトリとプロジェクト履歴のバッファーになっており、各開発者のローカル リポジトリが作業結果と中央のリポジトリのバッファーになっているのです。

このことは Git ユーザーの開発基本モデルに大きな変化を生じます。Git を利用する開発者は、変更を直接中央リポジトリにコミットするのではなく、ローカル リポジトリにコミットを蓄積できます。これには、フィーチャーを小規模なコミットに分割することが可能、関連性の強いコミットをグループ化したまま維持可能、中央リポジトリに公開する前にローカル リポジトリの整理が可能など、SVN 型のコラボレーションと比較して数多くの利点があります。これにより、開発者は独立した環境で作業できるようになり、他のユーザーとマージできる適切な区切りに作業が到達するまで他との統合を先延ばしにできます。チームにとっては頻繁に更新して小さなユニットにしておくのが得策であるため、独立した環境と統合の先延ばしにはそれぞれ固有のメリットがあります。Git のチーム コラボレーションに関するベスト プラクティスの詳細については、チームが Git workflow を構築する方法を参照してください。

Git Branch コマンド
関連資料

Git Branch コマンド

Bitbucket ロゴ
ソリューションを見る

Bitbucket Cloud での Git の使用方法についてのチュートリアルです。

差分ではなくスナップショットを保存


SVN と Git の間には実践的な相違がありますが、加えて基本構造もまったく異なる設計思想に基づいています。SVN ではファイルの差分を追跡するのに対し、Git のバージョン管理モデルはスナップショットに基づいています。例えば、SVN のコミットはリポジトリに存在する元のファイルとの差分で構成されます。それに対し、Git ではコミットのたびにそれぞれのファイルの内容すべてを記録します。

Git チュートリアル: 差分ではなくスナップショットを保存

これにより、あるリビジョンのファイルを再現する際に差分データから「組み立てる」必要がなく、それぞれのファイルのあらゆるリビジョンが Git の内部データベースから即時取得できるため、Git におけるほとんどの操作は SVN と比較してはるかに高速に動作します。

Git で採用されているスナップショットモデルは、ブランチツールやマージツールからコラボレーションワークフローにいたるまで、そのバージョン管理モデルのあらゆる面に広範な影響を及ぼしています。

よく使われるオプション


git commit

ステージされたスナップショットをコミットするコマンドです。このコマンドを実行するとテキストエディターが起動され、コミットメッセージの入力を求められます。メッセージの入力後、ファイルを保存してエディターを終了するとコミットが実行されます。

git commit -a

作業ディレクトリにおけるすべての変更のスナップショットをコミットします。これには追跡対象ファイル (過去に git add コマンドによって履歴に追加されたことのあるファイル) の修正のみが含まれます。

git commit -m "commit message"

渡されたコミット メッセージを使ってコミットを即座に作成するショートカット コマンドです。デフォルトでは、git commit はローカルで設定されたテキスト エディターを起動して、コミット メッセージの入力が求められます。-m オプションを渡すと、テキスト エディターは起動せずにインライン メッセージを表示します。

git commit -am "commit message"

-a オプションと -m オプションを組み合わせたパワー ユーザーのショートカット・コマンドです。この組み合わせではステージされたすべての変更のコミットを作成し、インライン コミット メッセージを取得します。

git commit --amend

このオプションを使うことで、コミットコマンドに新たな機能が加わります。このオプションを渡すと、直前のコミットが修正されます。新しいコミットを作成する代わりに、ステージした変更が直前のコミットに追加されます。このコマンドではシステムで設定されたテキストエディターが起動して、直前に指定したコミットメッセージを変更するよう求められます。


コミットを使って変更を保存する

以下のサンプルでは、現在のブランチにある hello.py という名称のファイルの内容を編集し、それをプロジェクト履歴にコミットする準備が整っていると仮定します。最初に git add コマンドを使用してそのファイルをステージし、次にステージされたスナップショットをコミットします。

git add hello.py

このコマンドは、hello.py をGit ステージング エリアに追加します。git status コマンドを使うと、この操作の結果を調べられます。

git status
On branch main
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
   new file: hello.py

緑の出力「new file: hello.py」は、後続のコミットで hello.py が保存されたことを示しています。コミットを作成するには次を実行します。

git commit

このコマンドを実行するとテキスト エディター (git config コマンドを使用して任意のエディターを指定できます) が起動され、コミットされる内容の一覧を表示すると共にコミット ログ メッセージの入力を求められます:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch main
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
#modified: hello.py

Git ではコミットメッセージの形式に関して制約はありませんが、1 行目にコミットの全体的説明を 50 字以内で記述し、2行目は空白行とし、3行目以降に変更内容の詳細を記述するのが標準的な形式です。以下はその例です:

Change the message displayed by hello.py

- Update the sayHello() function to output the user's name
- Change the sayGoodbye() function to a friendlier message

メールと同じように、コミット・メッセージの先頭行をタイトルとして使うのが一般的です。ログ・メッセージの残りの部分は本文と見なされ、コミット変更セットの詳細を説明するために使用されます。なお、開発者の多くはコミット・メッセージを現在形で記述する傾向があることに留意してください。これは、それぞれがリポジトリに対するアクションのように読むことができるため、履歴を書き換える操作をより直観的に理解できるという効果があります。

コミットの更新 (修正) 方法


上の hello.py のサンプルを引き続き使って、hello.py をさらに更新して以下を実行しましょう。

git add hello.py
git commit --amend

このコマンドでも設定済みのテキストエディターが開きます。ただ、今回は前に入力したコミットメッセージがあらかじめ入力されています。つまり、新しいコミットを作成するのではなく、前回のものを編集するのです。

要約


git commit コマンドは Git の中核を成す機能の 1 つです。後続のコミットにステージする変更を選ぶには、事前に git add コマンドを使っておく必要があります。その後、git commit を使って Git プロジェクト履歴のタイムラインに沿ってステージされた変更のスナップショットを作成します。git add の詳しい使い方については、関連するページを参照してください。git status コマンドは、ステージング・エリアと保留中のコミットの状態を調べるのに使用できます。

SVN と Git のコミットモデルには大きな違いがありますが、どちらも同じ用語を使っているため混同されることがよくあります。SVN で個人履歴を使っていた状態から Git を使い始めた場合、Git ではコミットのコストが低くて頻繁に使われることを覚えておくと良いでしょう。SVN のコミットはコストがかかり、リモートリクエストが発生しますが、Git のコミットはローカルで実行されて、効率的なアルゴリズムを採用しています。


この記事を共有する
次のトピック

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

一面のツールを使ってコラボレーションしている人たち

Bitbucket ブログ

DevOps のイラスト

DevOps ラーニング パス

Demo Den アトラシアン・エキスパートによる機能デモ

Bitbucket Cloud が、Atlassian Open DevOps とどのように連携するか

DevOps ニュースレター購読

Thank you for signing up