4

私はWebアプリケーションの開発に数か月を費やし、本番段階に近づいています。間もなく、このプロジェクトに1〜3人で開発グループを拡大する時が来ました。

私はSVNでの作業経験があまりありませんが、大企業の大部分にとっては明らかに選択であるため、SVNの長所は間違いなくコミット/チェックイン/チェックに費やす時間を上回っていると思います。アウトなど。

SVNを使用すると、ワークフローが少し複雑になるようです。O'ReillyMediaによるSubversionを使用したバージョン管理を読んだことがありますが、単独で開発する場合や、小さな（1〜3人）ワークグループ？

どうしますか？単独または小規模なワークグループで作業しているときのバージョン管理のワークフローは何ですか？

ありがとう！

4

3 に答える 3

6

いいえ、やり過ぎではありません。バージョン管理は、それが単独であるか、小規模または大規模なチームであるかに関係なく、プログラミングに不可欠です。いつでも以前のリビジョンに戻ることができるため、「間違った」変更を行う恐れがなくなります。コミットメッセージで変更が行われた理由を覚えています。一緒に何が変わったかを知っています。などなど

于 2010-05-31T09:56:07.363 に答える
4

他のSCMと同様に、バックアップ以上のものであることは間違いありません。

  1. 特定のリリースにタグを付けることができるため、リリースを構成するすべてのコードのポイントを特定できます。
  2. ソリューションの新しいバージョンの開発中にリリースのバグ修正を管理する必要がある場合など、さまざまな同時リリースのブランチを管理できます。
  3. 複数の開発者を管理し、SVNのマージ機能を使用して同時変更を処理できるため、開発者はお互いに足を踏み入れたり、お互いの変更を上書きまたは消去したりすることはありません。

他の開発者と一緒に開発するのはもちろんのこと、SCMなしで自分で開発することはありません。これはツールボックスのコアツールであり、遅かれ早かれaufaitを取得する価値があります。

私のワークフローは何ですか？使用しているチームとSCMによって異なります。

  1. SCMがそれをうまくサポートしている場合（Gitなど）、バグ/機能ごとにブランチを作成します。SVNは分岐時にそれほど熱くないので、これは当てはまらないかもしれません。
  2. 私は定期的にチェックイン/マージします。これを頻繁に行わないと、コードベースが作業中のコードベースから分岐し、その後のマージがより困難になります。さらに、チームメンバーに自分がしていることを可視化してもらいたいと考えています。
  3. 私の継続的インテグレーションプロセス（たとえば、TeamCity / Cruisecontrol / Hudosnなどの継続的ビルドエンジンを使用）は、ビルド/テストサイクルが成功すると、リリースをビルド/テストし、オプションでタグ付けします。
  4. 最終リリース用のブランチを作成し、リリース後のメンテナンスのためにこれを処理します。
于 2010-05-31T09:54:29.617 に答える
2

ブライアンの答えに追加することはあまりありません。別の方法として、Mercurial、Git、Bazaarなどの分散ソース管理システム（DSCM）を確認することをお勧めします。私見では、これらは小規模な開発者グループに最適であり、セットアップは非常に簡単ですが、それでも大規模なプロジェクトに拡張することができます。

Joel Spolskyによって書かれた、Mercurialに関する優れた入門チュートリアルは、http：//hginit.com/にあります。

リポジトリレイアウト
（ソース：hginit.com）

于 2010-05-31T10:07:36.993 に答える