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 hello.py
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 hello.py 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 hello.py
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>..." を使用してアンステージする)
#
#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

なお、開発者の多くはコミットメッセージを現在形で記述する傾向があることに留意してください。これは、それぞれがリポジトリに対するアクションのように読むことができるため、履歴を書き換える操作をより直観的に理解できるという効果があります。

Ready to learn Git?

Try this interactive tutorial.

今すぐ始める