SIerが実践する分散開発とバージョンコントロール - Qiita
オフショアA、Bとしましたが、同じ会社の別部署など、 とにかく別ロケーションで開発する場合を想定しています。 ソースの構成 おそらく、以下のように１つのJavaプロジェクト内にすべて書くのではないでしょうか？ デメリット バッチを書いている人が、オレオレライブラリやWEBのソースを改変する可能性がある。（オレオレライブラリ、WEBも然り） プロジェクトが太って行った時に、コンパイルなどに時間がものすごくかかる。（5000以上のJavaファイルが配置されているものを見たことがある） それぞれのソースでプロジェクトを分けているものも書こうかと思いましたが、 その場合は、システムでスタックをちゃんと組んでるかな、と思ったので省略。 リポジトリのモデル 従来型の場合は、以下のパターンのどちらかではないでしょうか？ リポジトリは分けている 最終的に社内のSVNリポジトリにオフショアA、Bのソースをマ
Subversionを使用し続けているプロジェクトがGitに移行することを考えてみた - Qiita
このページについて 中央集権型バージョン管理のCVSとSVN、分散バージョン管理のGit両方を各プロジェクトで使用してきた経験から、新規開発、保守開発でSVNを使用し続けているプロジェクトがGitを使うメリットについて考えて書いてみるページです。 あくまでも経験を下に主観で書いていきますので、いやいやその考え方は間違っているよ！とか、これも書いといて！というのがあれば、コメントやら編集リクエストなどください。 想定読者 Gitを使ってみたいけど、保守開発だからSVNからGitに乗り換えるのなんて無理だよ！と半ば諦めている方 SVNからGitに乗り換える提案をしたいから、乗り換えることで生じるメリット・デメリットが知りたいよ！という方 うちはSVNで構成管理をしてきたんだ！Gitなんか誰も使ったことないから何かあったら誰が責任取ってくれるんだ！と使用を許してくれない上司を説得したいという方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
