私たちはCIチームシティとAssemblaを通したsvn setupを持っています。私はソース管理を理解している、私のチームはそれに新しいですか？私たちはどのように仕事を進めるべきですか？現在、私たちの環境は整然としたものではありません。 Tracが私たちのグループのために働くように努めています。私たちはそれぞれの人が自分の支店で仕事をするにはどうすればよいですか？完了したら変更をトランクに併合しますか？または、彼らがトランクから仕事をすることを許可し、うまくいけばTeamcityは悪いものを捕まえるだろうか？Subversion、5人の開発者からなる小規模チームのベストプラクティス？
1をタグ付けしていますか？ チームが構成管理の初心者である場合、短期的な目標は、自分の仕事に最小の妨害を加えて制御された方法で作業させることです。つまり、個人の設定目標を短期的な目標と長期的な目標に分割する必要があります。チームが学ぶように長期目標を再定義する準備をしてください！
2.現在のところ、私たちの環境は整然としているわけではありません。 良い構成マネージャーはいつもこれを考えます。あなたがしたい最後のことは、あなたがプロセスを "本物の仕事"よりも好むという認識を与えることです。革命ではなく、動いて進化をここで考えてください。ソフトウェアと同様に、チームプロセスの定義には「計画」と良好なコミュニケーションが必要です。
3.私はまた、私たちのグループのためにTracを働こうとしています。 良い動き。最初に、TRACはあなたの開発者が何が起こっているかを見ることができます。しかし、チケット、マイルストーン、リビジョン、優先順位、そして開発者を困惑させる混乱を招くツールもたくさんあります。したがって、最初は、svnタイムラインと便利なdiffingツールのビューとしてtracを使用してください。彼らがツールセット自体に慣れているときにはチケット/マイルストーンなどを紹介し、それが得られない/必要がなければこれを使うことはできません。
4.私たちはそれぞれのブランチで作業する必要がありますか？完了したら変更をトランクに併合しますか？ 最終的には、おそらく。しかし、分岐/結合があなたのために解決するという問題を定義しましたか？覚えておいても、あなたのチームはこの種の問題になることはありません。ここに私の推薦は、あなたが問題に直面し、あなたの指導の下でチームとしてそれを解決するまで待つことです。
5.トランクをオフにすることを許可して、Teamcityが悪いことを捕まえることを願っていますか？ まず、はい。その後、問題が発生したときにCMについて知っている良いことをすべて紹介してください。
覚えておいてください - 偉大な構成管理システムではなく、ソフトウェア製品を構築しています。だから、シンプルにして、より良い製品をチームとして構築できるツール/プロセスだけを使用してください。途中で構成管理の価値を明らかに学んだので、開発者にも学びましょう。それらを導く、それらにプロセスを強制しないでください。明白なもの（「SVNは制御された方法でコードを共有できます」）から始め、あなたの経験を使ってそこから移動します。がんばろう！
私たちはそれぞれのブランチで作業する必要がありますか？完了したら変更をトランクに併合しますか？
私は通常、開発者ごとの支店がぎこちなくて、これは好きではないし、特定の開発者が他の人がこのように作業していることを理解するのは難しいブランチ。すべてのコミットでトランクにマージするように全員に依頼することでこれをいくらか緩和できますが、なぜブランチがあるのでしょうか？
トランクをオフにすることができますか、Teamcityが悪いものを捕まえることができますか？
ここで推奨するのは、開発者のバイインをチームルールにすることです。皆が更新してトランクにコミットし、コミットする前にローカルでテストを実行します。 Subversionのブランチは、機能の個別テストの根拠ではなく、今後のリリースに対応するような一連の機能のセットでより効果的に使用されます。
あなたのCIは、あなたが期待する状態にないことを警告するセーフティネットであるべきだと思います。しかし、開発者が最初に合格しないコードをチェックするべきではないと理解している場合に役立ちます。
1 - 更新
2 - コード
3 - テスト
4 - Update'n'merge
5 - テスト
6 - SVNで
リポジトリに変更がない限り、ループ4と5をループします。 – Scoregraphic
あなたは何を言っているのか分かりません。あなたはそれを改めて気にしますか？ – user154366
絶対に必要でない場合はブランチを使用しないでください。変更を行う前にローカルで更新してください。あなたの変更を行います。コードとテストを実行しているときに、リポジトリから更新し、起こり得る競合をマージし、テストを再実行してコミットします。大きな仕事に取り組んでおり、定期的にコードを実行するのが難しい場合（少なくとも毎日）、定期的に更新して、大きな驚きや合併を防ぐ。 – runarM
ブランチをコミット対処するように簡単ではありません彼らがgitにいるように。したがって、私は、ほとんどの日々の作業をトランク内で行う必要があり、ブランチで大きな破壊的な変更が発生するという意見があります。
注：これは私たちが私の会社でやる方法であり、かなりうまく機能します。
似たような状況で私たちは3人のチームであり、自分の経験が限られていても私はソースコントロールを求めています。私はこの記事が例外的に有用であることを発見しました：http://www.ericsink.com/scm/source_control.html
あなたのチームがそれをまだ読んでいないなら、彼らは間違いなく出発点です。
誰もが自分の枝で試してからトランクの方法に合併して、私は間違いから、痛いほど控えめに言っても紛らわしいと伝えます。あなたが最も経験豊かで新しい人たちであれば、そのブランチを一緒にマージする責任を負うことになる可能性があります。楽しいものではありません。
トランクを走っているすべての人は、これまでのところほとんど苦痛を感じていませんでした。あなたはすべて、別々のファイル上で互いの改善の恩恵を受けることができます。矛盾がない限り、差異は自動的に更新され、マージされます。また、あなたのチームはリビジョンコントロールの仕組みに慣れてゆき、徐々にそのメカニックに慣れてゆき、ブランチング&のマージを検討する価値があります。要するに
：それは長期的に報わます
:-)ベイビーステップ。
これは、我々はそれを使用する方法です：
trunktrunkに合併します。私はsvnをこの方法で使用しており、それについては一度も不平を言いませんでした。あなたの戦略は、あなたが開発しているソフトウェアの種類に依存していると思います。私の場合、それは多くの異なる顧客によって使用され、重要な環境（プラントオートメーション）でいくつかの異なるバージョンで使用可能な製品でした。
重く見えるかもしれませんが、うまくいき、多くのユーザーにサービスを提供することができました。この種のクリティカルなソフトウェアでは、誰もが新しいバージョンの内容を確認したいと考えています。
この種の制約がない場合は、1〜3で十分です。支店で働くことは時々苦しいです。
複数の主要プロジェクトを並行して実行する必要がある場合は、水銀やgitのようなDVCSを考慮する必要があります。
http://stackoverflow.com/questions/417599/svn-best-practices-working-in-a-teamの重複 –