つれずれなるままの開発日記(最近はFlexばかり..)

Archive for the ‘git’ Category

subversionのリポジトリをgitに変換はよくあると思うが、gitのリポジトリをSubversionに変換というのを今回やりたい。

というのも、何度もいっているが、中央には、Subversionで、各ワークをgitで私は使いたいからだ。
（これは、Tracとはviewvcとか、すでに構築してしまった環境を変えるのも面倒というのもある。）

しかし、今回はとりあえず、ネットにつながっていない環境で初めてしまったgitのリポジトリをSubversionに変換して、
再度、git-svnで再開したいのだ。

こんな用途を持っている人はあまりいないのか、WEBで方法を探したがすぐには見つからなかったので、
自分なりに、次のような手順でログ情報だけでも取り込むことにした。

Subversionのリポジトリを作成

ここでは、Subversionでのリポジトリを作成する方法は述べない。
で、svnで、trunk , tags, branches のディレクトリを作成し、コミットしておく。
これで、リビジョンは、[1]になったわけだ。

※どうやら、log情報がないとこれからやる処理がうまくいかないらしく、リビジョン1を作成するためにやった。

git-svnで、リポジトリの情報を取得

git svn clone svn://・・・・・ -T trunk -t tags -b branches

これで、gitとしてのワークができあがったことになる。

gitで育ててしまったワークをgit-svn のワークのリモートとして登録する。

ここでは、/home/foo/local.git がgitのリポジトリとする。
また、その名前を”org”としてつけた。

もちろん、このコマンドはgit-svn のワークの中で行う。

git remote add org /home/foo/local.git
git fetch org

パッチファイルを作成する。

ここで、git-mergeをはじめ行ったが、それでは、リビジョン１の前のログとなってしまい、Subversionにログを登録することができなかった。
そのために、git-format-patch を使った。

git format-patch -o patches master..org/master
git am patches/*.patch

できあがったログをSubversionにコミットする。

git svn dcommit

で終了だ。

gitでは、リモートリポジトリを複数登録できるのだが、このとき、あるリポジトリのあるコミット分だけ反映させたいという事がしたい時がある。
たとえば、オリジナルから派生して開発をしているが、オリジナルのバグ分だけ反映するといった使い方だ。

ここで、リモートリポジトリの登録から、そのリモートの変更分を取り込むまでの手順を記録しておきます。
もしかしたら、これよりいい方法があるかもしれませし、必要のない手順が含まれているかもしれませんが、
とりあえず、解決できる手順を覚書として記録しておきます。

1) リモートリポジトリを追加する

git remote add [name] [uri]

のようにします。
たとえば

git remote add myremote git://git.sourceforge.jp/xxxxxxx.xxxx.git

のようにします。

2)　追加したリモートリポジトリの情報をフェッチする

git fetch myremote

3) リモートから取り込みたいコミットを指定し、自分のワークにコミットする

 git cherry-pick [commit-id]

commit-idとは、git logを指定すると表示されるやつで、具体的には

git cherry-pick 947559c50d59e15b4e5817d8091f3e2862fe293d

のように使う。
ちなみに、この処理は同時にコミットするが、コミットせずに、git add した状態でとめておきたいならば

git cherry-pick --no-commit [commit-id]

のようにすれば、OKだ。

gitでは、ちょっとした開発やバグフィックスなどbranchを使用して開発する。
このために、頻繁にマージしたくなる。

ただし、ここであえて「マージ」と記述したのは、”git merge”のことではなく、
変更した内容を反映させたいという意味で「マージ」だ。

そのマージする際の、いろいろな手順にを覚書として記録しておく。

１）ブランチのコミットした内容も含めてマージする

git merge [ブランチ名]

２）ブランチの修正した内容すべての変更を取り込む

つまり、１）でやったこととほぼ同様だが、コミットはしない。

git merge --squash [ブランチ名]

これで、ブランチ上で行ったすべての変更が１つになって取り込まれる。

しかしながら、これでは、せっかく何度もブランチ上で育てたログが無駄になってしまう。
ログとソースをきれいにした状態で再作成したい場合にはこれではこまるので、
次の方法をとる。

３）パッチファイルを作成して、自由な単位でマージする

git format-patch -o dir_p mater..[ブランチ名]

たとえば

git format-patch -o p1 master..fix4
p1/0001-7.3.patch
p1/0002-7.4.patch

こんな感じに出力されます。

次に、そのパッチを当てるのですが、当て方が２種類。
こちらも、ログ情報なども含めて自動的にコミットするか？
または、修正の内容だけを反映して、後で自分でコミットするか？
です。

パッチをあててコミットも自動で行う

git am [パッチファイル]

で先ほどの出力例を使って実行すると・・・

git am p1/0001-7.3.patch
Applying: 7.3

修正の内容だけを反映する

git apply [パッチファイル]

git apply p1/0002-7.4.patch

これらの方法を使って、後で管理しやすいように修正の単位とログをきれいにできるので、
結構使うといいのではないでしょうか？

さて、gitの使い方を忘れないうちに、gitの使い方をメモっておきます。

git上で作成したブランチもgit-svnを使えばsvn上にブランチを作れると思っていたが、
どうやら、そうではないらしいので、git-svnを使ってsvnのブランチの使い方をメモしておきます。

１）ブランチを認識するようにワークを作成する

 git svn clone [uri] -T trunk -b branches -t tags

例）
 git svn clone file:///home/foo/svnroot/foo -t trunk -b branches -t tags

２）ブランチを作成する

※ gitのワーク上で作り方はわかりません。
   subversionのワークを使って行ってください。
  
３）作成したブランチ情報でgitのワークを更新

 git svn fetch svn

以下で、作成したブランチが確認できます。
 git branch -r
４）作成したブランチをgitのワークに取得

 git checkout -b [svnのブランチ名] [gitで認識するためのsvnブランチ名]

例）
 git checkout -b branch1 svn-branch1

のようにします。

５）ブランチで変更したソースをmasterにマージする

 git checkout master
 git merge [gitで認識するためのsvnブランチ名]

例)
 git merge svn-branch1

とのことだ。