Subversion, Git, Redmine, Hudson – 結局こうなった » tune web
前に考えていた開発プロセスの変更を色々試行錯誤してみてある程度固まってきました。過去の記事は以下からどうぞ。 Subversion, Git, Redmine, Hudson – 現状の連携 » tune web Subversion, Git, Redmine, Hudson – 今考えている連携 » tune web Subversion, Git, Redmine, Hudson – 今考えている連携2 » tune web ネットワークが切り離された外部チームとのやりとりは結局git bundleにしました。外部チームからはパッチでもらい、レビューした後に適用する。ある程度開発が進んだらgit bundleでリポジトリをコピーして外部チームに送付。外部チームはbundleファイルをそれぞれcloneして開発を行い、適宜git fetch/git pullしながら更新に追従します。タ
Subversion, Git, Redmine, Hudson – 今考えている連携2 » tune web
Subversion, Git, Redmine, Hudson – 今考えている連携 » tune webでいただいたコメント、実際にやってみて出来なかったことを反映してアップデートしてみました。 前回からの差分がいくつかあります。 git svnの窓口となるリポジトリとgit開発時のcentralとなるリポジトリを分けた。 内部設計書としてソースからDoxygenで生成したものを使っていたことを思い出したので追記 外部との作業項目のやりとりにRedmineからチケット一覧をExcelをエクスポートして使っているのを追記 お互いにパッチを送り合うのをやめて、パッチをもらったらgit-bundle(1)で作成したファイルを送るようにした。これなら物理的に離れていても同じリポジトリを使って作業出来る。 gitとSubversionの橋渡しにかなり悩んだのですが、実用Gitによると、窓口を1つ
Subversion, Git, Redmine, Hudson – 今考えている連携 - tune web
これからが本番、検索エンジンから来た方は先にSubversion, Git, Redmine, Hudson – 現状の連携 » tune webを読むことをおすすめします。上記が週末考えていた「こういう連携なら今の問題点を解消できるかな」と思えるフローです。「こうしたほうがいいよ」とかコメントありましたらお待ちしています。 1番のポイントはバージョン管理システムとしてGitを中心に据えました。社内はSubversionで統一するという規則があるので残すとして、開発チーム内ではgit svnを使ってGit化し、Subversionを直接触らないようにします。協力会社はSubversion縛りが無いのでGitで統一してもらいます。これまでは差分ファイルを送り合っていましたが、Gitを使えばパッチをうまく作り、修正単位でパッチファイルをやり取りすることが出来るでしょう。これまでは複数の修正がま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
