作業メモ
コミットをいくつか後もどりしてそれを一旦リリースな方向となってます。下記のブランチの元の部分を master にして以降はブランチ扱いって事で
o---o---o master / / o---o---o
が
o---o---o branch-x / / o---o / o---o---o master
みたいなカンジになれば良くていっちゃん下の末端が master になるカンジ。入門 Git の p.103 の記述によれば
- git commit -a でとりあえず作業中のソレを commit
git branch -b でブランチ作る- git branch でブランチ作る
- git log で確認
- git reset --hard master~3 とかで master を巻き戻し
- git checkout branch-x でブランチ切り替えて
- git reset HEAD^ で最初の commit 取り消し
今気がついたのですが、基本的な使い方として開発中のソレは branch で管理するのかなぁ。あと、タグを使ってリポジトリから取り出す方法ってどうやるんだろ。
タグ付けて checkout
との事。やはりそうか。入門Git 的には p.227 の 13.11. 歴史探訪なあたり。なので、作業リポジトリを上記な形にして共用リポジトリに push して差し上げたら、clone して checkout してもらえれば歴史を進めても大丈夫なのか。
間違えた
git branch に -b は不要。
盛り込み
以下。
$ git commit -a -m 'tempolary commit' [master 0c4dfe9] tempolary commit 16 files changed, 35 insertions(+), 60 deletions(-) $ git branch fix-bugs $ git log $ git reset --hard master~4
で、master の位置が前にずれた。実は上記の作業リポジトリはブランチ作ってマージしてるので、そのあたりのカウントの仕方がデフォルトな数え方ではないのかなぁ。
対処
ええと、共用リポジトリには上記の templary commit な直前の commit までの歴史があるので、
- clone してきて master を変更
- 当初目論んでいた状態になったら作業リポジトリの diff とって patch アテる
という方向でナニ。おそらくは作業リポジトリでの復帰はできるんだと思いますが、あまりワケワカってねぇヤツがごにょごにょしたら壊れるだけと判断。
で、戻りのカウントなんですが以下な状態の
master v o---o / / ---o---o ^ here
master から here まで巻き戻す場合には 2 つ前、というカウントになる模様。clone してきて以下でなんとかなった模様。
$ git branch fix-bugs $ git reset --hard master~2 HEAD is now at 4c3f764 Label name changed from Register to Upload $
あとは変更盛り込みかけの作業リポジトリから format-patch なソレを上記のナニに git am したら OK ッスか。あと tag もナニしないとダメですが、とりあえず一服。
続き
で、format-patch なんですが、commit してないとダメでした。とほほ。一旦作業リポジトリにて
$ git reset HEAD^ $
してたんですが、再度 commit
$ git commit -a -m 'tempolary commit' [fix-leaks 3713a72] tempolary commit 16 files changed, 35 insertions(+), 60 deletions(-) $ || で、format-patch 取得。 >|| $ git format-patch HEAD^ 0001-tempolary-commit.patch $
次に master を元に戻したディレクトリに移動して以下。
$ git am ../hoge/0001-tempolary-commit.patch
微妙なエラーが出力されておりましたが、コピー元とコピー先にて git reset HEAD^ して git diff の結果を目視で見比べてみましたが、変わりはなかったのでヨシとしてます (を
これを共用方面にも push しておきたいのですが、いいのか悪いのか判断できてないです。
と思ったら
master 側に移動できん。やはり commit せい、という事か。どうしたものか。やはり現状の変更は commit しといて云々?
現状の master を push したら共用リポジトリはどうなるんでしょ。ローカルで clone しとくか。てか、ディレクトリごとコピーしとくか。
push
バックアップ作ったので push してみた。
$ git push origin master To hoge@fuga:/home/hoge/git/BeatMaster.git ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'hoge@fuga:/home/lexues/git/BeatMaster.git' To prevent you from losing history, non-fast-forward updates were rejected. Merge the remote changes before pushing again. See 'non-fast forward' section of 'git push --help' for details. $
うーん。マージしてから push しれ、という事か。てか、こーゆーケイスって branch を破棄する事だってあり得る訳で、どうしたものやらと言いつつ微妙だなぁ。
一応現行のリポジトリはコピー取ってるので、、、って既存の作業リポジトリから初期化したリポジトトリへの push の方法って微妙だぞ。わははは。
そもそもの
戦略というか作戦がダウトだった可能性大。てか、マージしろよ、って事でしょうな。とりあえずメモが gdgd になってるのは分かってるんですが続けます。
とりあえず作業途中の commit に名前を付けて checkout できれば良いのでそれを試す。
$ git tag release-2.0 4c3f76421f7ad2d0071f30f77d1a819e344842b5 $ git tag -l release-2.0 $ git checkout release-2.0 Note: moving to 'release-2.0' which isn't a local branch If you want to create a new branch from this checkout, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new_branch_name> HEAD is now at 4c3f764... Label name changed from Register to Upload $
失敗? って思ったら git log とかを見てみるとそうなっている模様。タグを push するには以下で良いらしいので、今から試験。
$ git push --tags
とりあえず、この状態で clone と checkout の方法を fwd な方向。
- git clone
- git checkout release-2.0
して云々、ですか。。
それにしても
- 元の状態がバックアップで残っているとは言え、最終の修正が盛り込まれていない
- 最終の修正については、別ディレクトリにリポジトリがあるものの、fast forward 的にダウト
- 歴史を巻き戻しちゃってるし
- 無理矢理マージして歴史をすすめた方が良い?
うーん、困った困った。