git-svnを利用した運用を考える - Qiita
最近、諸事情あってsubversionからgitへプロジェクトの半ばでバージョン管理を変更しました。その際にちょっと変わった形でgit-svnの運用を行う事になったのでやりかたに関して簡単にログを残しておきます。 プロジェクトを取り巻く事情 今まではSubversion(仮にメインとします)を用いた運用を行っていたのですが、気軽にtrunkに対してコミットする事が出来ない事情がありました。では、メインSubversion上にbranchをたてればいいじゃんという話になるのですが、ブランチすら気軽に切る事が出来ない状態でした。その上、メインのSubversionにコミットすることが可能なのはコミッターだけとなっておりコミッターの負担が増えつつありました。 今までの運用 今まではメインSubversionとは別に 同期しないSubversion(仮にローカルとします)を別途立てて、なんと手動で
git-svnを使うときのベストプラクティス - Life goes on
いつもの事ですが、タイトルは釣り。 現在のプロジェクトにアサインされてから、VCSがsvnに逆戻りしてしまったのでかれこれ5ヶ月近くgit-svnを使用してます。初めの頃に2~3回程checkoutしなおすレベルの失敗があったりしましたが、ここの所はそれほど問題無く運用してます。 gitとsvnでもう根本の仕組みから全然違うんで、ある程度しょうがないのですが、ちょっとばかり気をつけないとハマる可能性があるので、その点について語ります。 svnがremoteになってるブランチは 絶対 に直接コミットなどしない 自分の中ではこれが鉄則になってます。例えば普通のsvnの構成だと、trunkがgitのmasterブランチになりますが、何かの修正するって時にはどんだけ軽い修正とかでも絶対にトピックブランチを作ってます。 原則として、masterブランチ(や、他のsvnで作ってあるブランチ)には、gi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git:masterからsvn:trunkに同期する方法(その2)
git:masterからsvn:trunkに同期する方法
Git - git-svn Documentation
Loading...
【TECH】gitとsvnの自動同期スクリプトの作成してみた！ | Interfactory HumanResources MEDIA
Migration from SVN to Git! a developer guide to git-svn
