- 
  
1. 使い始める
- 1.1 バージョン管理に関して
 - 1.2 Git略史
 - 1.3 Gitの基本
 - 1.4 コマンドライン
 - 1.5 Gitのインストール
 - 1.6 最初のGitの構成
 - 1.7 ヘルプを見る
 - 1.8 まとめ
 
 - 
  
2. Git の基本
- 2.1 Git リポジトリの取得
 - 2.2 変更内容のリポジトリへの記録
 - 2.3 コミット履歴の閲覧
 - 2.4 作業のやり直し
 - 2.5 リモートでの作業
 - 2.6 タグ
 - 2.7 Git エイリアス
 - 2.8 まとめ
 
 - 
  
3. Git のブランチ機能
- 3.1 ブランチとは
 - 3.2 ブランチとマージの基本
 - 3.3 ブランチの管理
 - 3.4 ブランチでの作業の流れ
 - 3.5 リモートブランチ
 - 3.6 リベース
 - 3.7 まとめ
 
 - 
  
4. Gitサーバー
- 4.1 プロトコル
 - 4.2 サーバー用の Git の取得
 - 4.3 SSH 公開鍵の作成
 - 4.4 サーバーのセットアップ
 - 4.5 Git デーモン
 - 4.6 Smart HTTP
 - 4.7 GitWeb
 - 4.8 GitLab
 - 4.9 サードパーティによる Git ホスティング
 - 4.10 まとめ
 
 - 
  
5. Git での分散作業
- 5.1 分散作業の流れ
 - 5.2 プロジェクトへの貢献
 - 5.3 プロジェクトの運営
 - 5.4 まとめ
 
 
- 
  
6. GitHub
- 6.1 アカウントの準備と設定
 - 6.2 プロジェクトへの貢献
 - 6.3 プロジェクトのメンテナンス
 - 6.4 組織の管理
 - 6.5 スクリプトによる GitHub の操作
 - 6.6 まとめ
 
 - 
  
7. Git のさまざまなツール
- 7.1 リビジョンの選択
 - 7.2 対話的なステージング
 - 7.3 作業の隠しかたと消しかた
 - 7.4 作業内容への署名
 - 7.5 検索
 - 7.6 歴史の書き換え
 - 7.7 リセットコマンド詳説
 - 7.8 高度なマージ手法
 - 7.9 Rerere
 - 7.10 Git によるデバッグ
 - 7.11 サブモジュール
 - 7.12 バンドルファイルの作成
 - 7.13 Git オブジェクトの置き換え
 - 7.14 認証情報の保存
 - 7.15 まとめ
 
 - 
  
8. Git のカスタマイズ
- 8.1 Git の設定
 - 8.2 Git の属性
 - 8.3 Git フック
 - 8.4 Git ポリシーの実施例
 - 8.5 まとめ
 
 - 
  
9. Gitとその他のシステムの連携
- 9.1 Git をクライアントとして使用する
 - 9.2 Git へ移行する
 - 9.3 まとめ
 
 - 
  
10. Gitの内側
- 10.1 配管(Plumbing)と磁器(Porcelain)
 - 10.2 Gitオブジェクト
 - 10.3 Gitの参照
 - 10.4 Packfile
 - 10.5 Refspec
 - 10.6 転送プロトコル
 - 10.7 メンテナンスとデータリカバリ
 - 10.8 環境変数
 - 10.9 まとめ
 
 
- 
  
A1. 付録 A: その他の環境でのGit
- A1.1 グラフィカルインタフェース
 - A1.2 Visual StudioでGitを使う
 - A1.3 EclipseでGitを使う
 - A1.4 BashでGitを使う
 - A1.5 ZshでGitを使う
 - A1.6 PowershellでGitを使う
 - A1.7 まとめ
 
 - 
  
A2. 付録 B: Gitをあなたのアプリケーションに組み込む
- A2.1 Gitのコマンドラインツールを使う方法
 - A2.2 Libgit2を使う方法
 - A2.3 JGit
 
 - 
  
A3. 付録 C: Gitのコマンド
- A3.1 セットアップと設定
 - A3.2 プロジェクトの取得と作成
 - A3.3 基本的なスナップショット
 - A3.4 ブランチとマージ
 - A3.5 プロジェクトの共有とアップデート
 - A3.6 検査と比較
 - A3.7 デバッグ
 - A3.8 パッチの適用
 - A3.9 メール
 - A3.10 外部システム
 - A3.11 システム管理
 - A3.12 配管コマンド
 
 
2.4 Git の基本 - 作業のやり直し
作業のやり直し
どんな場面であっても、何かをやり直したくなることはあります。 ここでは、行った変更を取り消すための基本的なツールについて説明します。 注意点は、ここで扱う内容の中には「やり直しのやり直し」ができないものもあるということです。 Git で何か間違えたときに作業内容を失ってしまう数少ない例がここにあります。
やり直しを行う場面としてもっともよくあるのは、「コミットを早まりすぎて追加すべきファイルを忘れてしまった」「コミットメッセージが変になってしまった」などです。
そのコミットをもう一度やりなおす場合は、--amend オプションをつけてもう一度コミットします。
$ git commit --amend
このコマンドは、ステージングエリアの内容をコミットに使用します。 直近のコミット以降に何も変更をしていない場合 (たとえば、コミットの直後にこのコマンドを実行したような場合)、 スナップショットの内容はまったく同じでありコミットメッセージを変更することになります。
コミットメッセージのエディタが同じように立ち上がりますが、既に前回のコミット時のメッセージが書き込まれた状態になっています。 ふだんと同様にメッセージを編集できますが、前回のコミット時のメッセージがその内容で上書きされます。
たとえば、いったんコミットした後、何かのファイルをステージするのを忘れていたのに気づいたとしましょう。そんな場合はこのようにします。
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
最終的にできあがるのはひとつのコミットです。二番目のコミットが、最初のコミットの結果を上書きするのです。
ステージしたファイルの取り消し
続くふたつのセクションでは、ステージングエリアと作業ディレクトリの変更に関する作業を扱います。
すばらしいことに、これらふたつの場所の状態を表示するコマンドを使用すると、変更内容を取り消す方法も同時に表示されます。
たとえば、ふたつのファイルを変更し、それぞれを別のコミットとするつもりだったのに間違えて git add * と打ち込んでしまったときのことを考えましょう。
ファイルが両方ともステージされてしまいました。
ふたつのうちの一方だけのステージを解除するにはどうすればいいでしょう?
git status コマンドが教えてくれます。
$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
    renamed:    README.md -> README
    modified:   CONTRIBUTING.md
“Changes to be committed” の直後に、"use git reset HEAD <file>... to unstage" と書かれています。このアドバイスに従って、CONTRIBUTING.md ファイルのステージを解除してみましょう。
$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M	CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
    renamed:    README.md -> README
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
    modified:   CONTRIBUTING.md
ちょっと奇妙に見えるコマンドですが、きちんと動作します。
CONTRIBUTING.md ファイルは、変更されたもののステージされていない状態に戻りました。
| 
 注記 
 | 
 
  | 
今のところは、`git reset`については上記の魔法の呪文を知っておけば十分でしょう。リセットコマンド詳説で、より詳細に、`reset`の役割と使いこなし方について説明します。色々とおもしろいことができるようになりますよ。
ファイルへの変更の取り消し
CONTRIBUTING.md に加えた変更が、実は不要なものだったとしたらどうしますか?
変更を取り消す (直近のコミット時点の状態、あるいは最初にクローンしたり最初に作業ディレクトリに取得したときの状態に戻す) 最も簡単な方法は?
幸いなことに、またもや git status がその方法を教えてくれます。
先ほどの例の出力結果で、ステージされていないファイル一覧の部分を見てみましょう。
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
    modified:   CONTRIBUTING.md
とても明確に、変更を取り消す方法が書かれています 。 ではそのとおりにしてみましょう。
$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
    renamed:    README.md -> README
変更が取り消されたことがわかります。
| 
 重要 
 | 
 ここで理解しておくべきなのが、`git checkout — [file]`は危険なコマンドだ、ということです。 あなたがファイルに加えた変更はすべて消えてしまいます。変更した内容を、別のファイルで上書きしたのと同じことになります。そのファイルが不要であることが確実にわかっているとき以外は、このコマンドを使わないようにしましょう。  | 
やりたいことが、「ファイルに加えた変更はとっておきつつ、一時的に横に追いやっておきたい」ということであれば、[ch03-git-branching] で説明する stash やブランチを調べてみましょう。一般にこちらのほうがおすすめの方法です。
Git にコミットした内容のすべては、ほぼ常に取り消しが可能であることを覚えておきましょう。
削除したブランチへのコミットや --amend コミットで上書きされた元のコミットでさえも復旧することができます (データの復元方法については データリカバリ を参照ください)。
しかし、まだコミットしていない内容を失ってしまうと、それは二度と取り戻せません。