いがいが日記

_ [git] gitでステージングした環境まで戻す

新しい職場ではコード管理にgitを使ってます。

git、本を読んで概要はつかんでいたのですが、

使ってみるといろいろと新しい発見があります。

今日は「add して commit してない状態(ステージ状態）へ戻したい」という状況になりました。

gitに管理されていてステージにあがっているAというファイルの他に、

untracked(管理外)のB,C,D,,,という多数のファイルがある状況で、

ステージされたAへ戻したいというもの。

$ git co HEAD .

だとcommit状態(HEAD)へ戻り、untrackedなファイルも残ります。

そこで、以下で対応しました。

---

■近道策

$ git checkout A # worikingのAがステージの状態へ戻る

$ git clean -f -d # untrackedなファイルとディレクトリが消える

■安全策（ステージ上のファイルをコミット）

$ git commit # ステージのAがコミットされる

$ git checkout HEAD . # worikingのAが↑の状態へ戻る

$ git clean -f -d # untrackedなファイルとディレクトリが消える

必要であればcommitを消してもOKです。

$ git reset --hard HEAD^ #HEADの1つ前(^)へコミットを修正＝直近のコミット削除

---

Subversionと大きく違うのはステージがあることと、マージの概念でしょうか。

ステージがあるので、diffをとるときも以下のように違いがあります。

$ git diff # ステージとworkingを比較

$ git diff HEAD # 最新コミットとworkingを比較

マージはSVNのようにworkingへ別ブランチのコミットを持ってくるんじゃなくて、

branchの流れを本流に合流させる、コミットを操作するイメージ。

あとはリモートのブランチが変更されたときはローカルで

$ git remote update

を打たないと反映されないことも使ってみて分かりました。

最後に、「それはこっちに置いといて」な便利機能stash。

workingの変更をリスが木の実を土に埋めておくように脇に置いておいて、

workingをきれいさっぱりしてくれます。

（ただし、ここで脇に置くのはtrackedなファイルだけ）

git、便利ですが手に馴染むにはまだ時間がかかりそうです。

追記：リモートのブランチが消えない件については2010年4月29日の日記に追記しました。

$ git remote update でダメなときは

$ git pull --prune も試してみてください。

追記(2010.5.9)：machuさんのツッコミを受けまして、

「書いてから気づいたけど、ファイルAをステージに戻すには

workingにあるAを消して、git co A でもいいね。」

の内容を踏まえて書き直しました。machuさんありがとう！