subversion-branching-model.html
この方針により、次のようなことができるようになります。 いつでも安全にリリースできるベースラインが欲しい。 trunkはいつでも安全にリリース可能。 作業中に緊急バグ対応など割り込み作業に対応したい。 branches/xxxに開発中ソースコードを格納して、新たにbranches/yyyを分岐することで安全に切り替えることができる。 作業中ソースコードを複数チームでキャッチボールしたい。 業務チームで開発 -> 品質管理チームでレビュー -> 構成管理チームでマージ -> ビルドチームでリリース、といったキャッチボール。 branches/xxxに開発中ソースコードを格納して、各チームで共有することができる。 作業完了まで自PCの中にしかソースコードがないのはツライので、作業中でもコミットしたい。 branches/xxxに頻繁にコミットしても良い。 次に、これらのフォルダの運用手順を説明
二カ月間ブランチを利用した開発フローを実践して感じたメリットとデメリット | DevelopersIO
本記事は当初SVNとGitの比較として「ブランチを用いた開発フロー」のメリット・デメリットについて記載していましたが、 「SVNでもブランチを利用できること」「分散型という言葉に対する記載の誤り」についてご指摘をいただきました。 そのため、ブランチを利用した開発フローに対して感じたことを焦点に記事を修正しております。誤った情報を記載していたこと、SVNに対して誤ったイメージをもつ可能性のある記載をしていたことに対し、深くお詫び申し上げます。 Gitをまともに使い始めて約二ヶ月がたちました。 特に、「ブランチをきる」「修正する」「レビューする」「マージする」という、おそらくGitで想定されている開発フローに沿っての開発はクラスメソッドに入社してからが初めてです。 6月に入社する以前は、開発用のソースコード管理には主にSVNを利用し、1つのバージョンの流れに全ての修正をコミットしていくフローで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
