git add

The git add command adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit. However, git add doesn't really affect the repository in any significant way—changes are not actually recorded until you run git commit.

In conjunction with these commands, you'll also need git status to view the state of the working directory and the staging area.


git add <file>

Stage all changes in <file> for the next commit.

git add <directory>

Stage all changes in <directory> for the next commit.

git add -p

Begin an interactive staging session that lets you choose portions of a file to add to the next commit. This will present you with a chunk of changes and prompt you for a command. Use y to stage the chunk, n to ignore the chunk, s to split it into smaller chunks, e to manually edit the chunk, and q to exit.


The git add and git commit commands compose the fundamental Git workflow. These are the two commands that every Git user needs to understand, regardless of their team’s collaboration model. They are the means to record versions of a project into the repository’s history.

Developing a project revolves around the basic edit/stage/commit pattern. First, you edit your files in the working directory. When you’re ready to save a copy of the current state of the project, you stage changes with git add. After you’re happy with the staged snapshot, you commit it to the project history with git commit.

Git チュートリアル: git add スナップショット

The git add command should not be confused with svn add, which adds a file to the repository. Instead, git add works on the more abstract level of changes. This means that git add needs to be called every time you alter a file, whereas svn add only needs to be called once for each file. It may sound redundant, but this workflow makes it much easier to keep a project organized.


ステージングエリアは、Git が有するユニークな機能のひとつであり、SVN (あるいは Mercurial) に慣れた人にとっては理解しにくい概念かも知れません。これは、作業ディレクトリとローカルリポジトリとの間のバッファーであると考えるとよいでしょう。


When you’re starting a new project, git add serves the same function as svn import. To create an initial commit of the current directory, use the following two commands:

git add .
git commit

Once you’ve got your project up-and-running, new files can be added by passing the path to git add:

git add
git commit

上の二つのコマンドは、既存ファイルに加えられた変更を記録する場合にも使用します。即ち、Git は新規ファイルを作成したことによる変更と既にリポジトリに保存されているファイルの内容の変更を区別しません。

git commit

The git commit command commits the staged snapshot to the project history. Committed snapshots can be thought of as “safe” versions of a project—Git will never change them unless you explicity ask it to. Along with git add, this is one of the most important Git commands.

While they share the same name, this command is nothing like svn commit. Snapshots are committed to the local repository, and this requires absolutely no interaction with other Git repositories.


git commit

Commit the staged snapshot. This will launch a text editor prompting you for a commit message. After you’ve entered a message, save the file and close the editor to create the actual commit. git commit -m "<message>"

Commit the staged snapshot, but instead of launching a text editor, use <message> as the commit message.

git commit -a

Commit a snapshot of all changes in the working directory. This only includes modifications to tracked files (those that have been added with git add at some point in their history).


Snapshots are always committed to the local repository. This is fundamentally different from SVN, wherein the working copy is committed to the central repository. In contrast, Git doesn’t force you to interact with the central repository until you’re ready. Just as the staging area is a buffer between the working directory and the project history, each developer’s local repository is a buffer between their contributions and the central repository.

このことは Git ユーザーの開発基本モデルに大きな変化を生じます。Git を利用する開発者は、変更を直接中央リポジトリにコミットするのではなく、ローカルリポジトリにコミットを蓄積することができます。これには、フィーチャーを小規模なコミットに分割することが可能、関連性の強いコミットをグループ化したまま維持可能、中央リポジトリに公開する前にローカルリポジトリの整理が可能など、SVN 型のコラボレーションと比較して数多くの利点があります。これにより、開発者は独立した環境で作業することができるようになり、また作業が適切な区切りを迎えるまで他との統合を遅らせることができます。


Aside from the practical distinctions between SVN and Git, their underlying implementation also follow entirely divergent design philosophies. Whereas SVN tracks differences of a file, Git’s version control model is based on snapshots. For example, an SVN commit consists of a diff compared to the original file added to the repository. Git, on the other hand, records the entire contents of each file in every commit.

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

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

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

The following example assumes you’ve edited some content in a file called and are ready to commit it to the project history. First, you need to stage the file with git add, then you can commit the staged snapshot.

git add
git commit

This will open a text editor (customizable via git config) asking for a commit message, along with a list of what’s being committed:

# 変更に対するコミットメッセージを入力してください。
# で開始する行では、「#」は無視され、空のメッセージはコミットを中止します。
# ブランチ master 
# コミット対象の変更:
# ("git reset HEAD <file>..." を使用してアンステージする)

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

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


Ready to learn Git?

Try this interactive tutorial.