- 243 名前：デフォルトの名無しさん mailto:sage [2011/10/10(月) 07:39:12.71 ]
- git branch a
git checkout a
でコード修正作業用のブランチに移動する。
このブランチ内で、各ソースファイルを修正して、適当に数行〜数十行修正する度に
git commit -a -m"適当な名前"
でコミットしてしまう。
この段階は試行錯誤の段階なので、数手前に戻りたい場合も出てくる、
その場合は
git log 修正してたファイル名 // 修正してたファイルの関連してるコミットの一覧を表示する
git diff 12345678 修正してたファイル名 > p // 戻りたい位置との差分パッチを得る。 12345678 はコミットIDの例
patch -R < p // パッチを充てて、ファイル状態を修正前に戻す
ひと通り、コード修正が終わったとして、そのコミットログはコメントも適当だし、試行錯誤の後も残ってて汚れてるので、
master との比較で最終結果を一つのパッチにまとめる。
git diff master > p
このパッチをmasterに充てる。
git checkout master
patch < p
git commit -a -m"正式なコミットコメント"
作業中の試行錯誤をgitを活用しながら進めることができ、最終的な修正結果は一つのパッチにまとめてコミットを綺麗な状態で行える。
もちろんパッチを綺麗にしようとしなければ、汚いログのままコミットしてもいいし、作業中の手戻りにgitを使わず古典的なバックアップファイルで行ってもいい。
ステージは、パッチを意味のあるまとまり毎に分けてコミットするためのもの。全部ひとまとめにコミットしてもいい場合は必要ない作業。
gitだと、修正範囲の狭いシンプルな複数のパッチが好まれる。様々な修正が含まれたごった煮パッチ１個にまとめてコミットすると嫌がられる。
|
 |
