17

SVN ではtrunk、メインの開発に推奨される場所であり、私はすべてのプロジェクトでこの規則を使用しています。ただし、これはトランクが時々不安定になったり、壊れたりすることを意味します。これは、たとえば次の場合に発生します。

  • 私は間違って何かをコミットします
  • SVN の動作が原因で、単にトランクを壊さなければならない場合。標準的な例はファイルの名前変更です。最初にファイルの名前変更をコミットし、後でさらに変更を行う必要があります。ただし、ファイルの名前変更では、名前空間またはクラス名の変更を反映するためにコードのリファクタリングが必要になる場合があるため、基本的には 1 つのロジック操作を 2 つのステップでコミットする必要があります。そして、ビルドはステップ 1 と 2 の間で壊れています。

何かを誤ってコミットするのを防ぐツール (たとえば、TeamCity やコミットの遅延) があると想像できますが、2 番目の問題を本当に克服できますか? そうでない場合は、いくつかのブランチで「ワイルド開発」を行い/branch/dev、ビルドがかなり安定している場合にのみトランクにマージする方がよいのではないでしょうか?

4

10 に答える 10

25

トランクは常にコンパイルする必要があります。重大な変更を行う必要がある場合は、ブランチを使用して後で変更をマージする必要があります。

SVN ブックのこの章を読んでください: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

于 2008-09-30T16:21:10.837 に答える
11

SCM のベスト プラクティスに関するこの記事を読むことをお勧めします。

記事からの抜粋:

メインラインを持つ。「メインライン」または「トランク」は、永遠に進化するコードラインの分岐です。メインラインは、ほぼすべての変更 (メンテナンス修正と新機能の両方) の最終的な目的地を提供し、ソフトウェア製品の主要な線形進化を表します。リリース コードラインと開発コードラインはメインラインから分岐され、分岐で発生した作業はメインラインに反映されます。

編集: SCM Patternsも読むことをお勧めします。

于 2008-09-30T16:21:32.677 に答える
11

それは本当にあなたの環境に依存します。場合によっては、トランクが一時的に壊れても大したことではありません。ただし、2 ～ 3 人以上で作業している場合は、おそらく適切ではありません。

その場合は、枝をもっと自由に使ったほうがいいと思います。それらは、セットアップと再マージが簡単です (物事が同期しすぎないようにする場合)。

もちろん、すべての開発者が同じブランチを使用している場合、実際には何も得られません。/branch/dev という名前のトランクが作成されるだけですが、トランクが壊れていることは依然として大きな問題です! 少数の開発者だけがそれぞれに取り組むようにブランチを分解してください。

于 2008-09-30T16:23:25.013 に答える
6

トランクは、進行中の開発が行われることになっている場所です。誰もが変更をコミットする前にテストしている場合、「壊れた」コードで問題が発生することはありません。経験則としては、変更をコーディングした後で更新を行う (リポジトリから最新のコードをすべて取得する) ことです。次に、ビルドして単体テストを行います。すべてがビルドされて機能する場合は、チェックインしても問題ありません。

リリースの準備ができたら、ブランチを作成します。テストはブランチに対してリリース検証を行うことができます。問題が見つかった場合は、ブランチとトランクに修正が加えられ、ブランチの新しいカットがテスト用に提供されます。その間、開発者は忙しく新しい変更をトランクに追加しています。

つまり... テストによって特定された問題と、これらの些細な問題に対する優れた解決策は、ブランチとトランクの両方で最新のものであり、テスト フォークには作業する安定したカットがあり、テストが現在のリリースを検証している間、開発は前進し続けています。

ハンニバルが「Aチーム」でいつも言ったように、「計画がまとまったときが大好きです」。

于 2008-09-30T16:50:43.527 に答える
3

Subversion を使用するチームは、多くの場合、マージに対して病理学的な嫌悪感を抱いています。1.5 より前では、マージは失敗しやすい長く複雑なプロセスだったからです。多くの人が一緒に動作する多くの異なるモジュールに取り組んでいるため、常に動作するトランクを持つことが絶対に必要な十分な開発者がいる場合、分岐開発は確かに役立ちます。

ちなみに、ファイルの名前を変更しても、編集は許可されています。私はいつもそうしています。

于 2008-09-30T16:50:54.773 に答える
2

短期間の開発ブランチの作成を簡素化するために、いくつかのシェルスクリプトを作成しました。

# Create new branch and switch to it
function svn_bswitch()
{
   branch=$1; shift
   msg="$1"; shift

   URL=$(svn info . | sed -ne 's@URL: \(.*\)@\1@p')
   REPO=$(svn info . | sed -ne 's@Repository Root: \(.*\)@\1@p')
   BRANCH_URL=$REPO/branch/$branch

   svn copy $URL $BRANCH_URL -m "$msg"
}


# Switch to a branch or tag
function svn_switch()
{
  d=$1; shift
  REPO=$(svn info . | sed -ne 's@Repository Root: \(.*\)@\1@p')
  URL=$REPO/$d
  svn switch $URL
}
于 2008-09-30T18:27:02.733 に答える
1

いいえ、トランクは最適な場所ではありません。私たちの組織では、常にこのアプローチに従います。トランクにはリリース コードが含まれているため、常にコンパイルされます。新しい各リリース/マイルストーンで、新しいブランチを開きます。開発者がアイテムを所有するときはいつでも、このリリース ブランチへの新しいブランチを作成し、テスト後にリリース ブランチにマージします。システム テストの後、リリース ブランチはトランクにマージされます。

添付の画像は大雑把な表現です。代替テキスト

于 2008-09-30T16:49:40.050 に答える
1

いいえ、トランクは開発レベルのコードをコミットするのに最適な場所ではありません。私たちの環境では、トランクを本番環境にデプロイされたもののミラーと見なしています。Web 開発とアプリケーション開発ではワークフローが異なる場合がありますが、トランクには最新の運用変更が含まれている必要があります。

私たちは開発ブランチ、つまり branch/feature1 で作業を行い、branchs/feature1 --> tags/feature1-qa1 をコピーして qa タグを作成し、branchs/feature1 のバグを修正して tags/feature1-qa1 などを作成します。デプロイの準備ができたら、トランクへの最後のマージ以降にブランチ/機能 1 で発生したすべての変更が、最終リリース タグ (tags/5.1.0) を作成する前にトランクにマージされます。

ワークフローは、チームのセットアップ方法や、現在のプロジェクト/環境の種類によって異なる場合があります。

于 2009-06-17T07:41:19.643 に答える
1

当社ではトランクの夜間ビルドを行っています。誰もが自分のコードをテストして、チェックインする前に少なくともコンパイルできるようにすることが期待されます。ナイトリー ビルドが失敗した場合、問題のあるコードは修正されるまで削除されます。

最も重要な部分は、Subversion の役割と、コンパイルされるコードのみをチェックインすることがなぜ重要なのかを誰もが理解することだと思います。

于 2008-09-30T16:35:35.530 に答える
1

古き良き「安定したトランク、ブランチの開発」プロセスが問題になる別の例:

あなたは、おそらくユーザーが提供する多くのライブ データに依存する Web アプリケーションを開発しています。何らかの理由で、依存するデータベース バックエンド (-s) または外部ファイル システムの別のインスタンスを生成するだけではありません。(たとえば、環境にデータ モデルの移行が欠けている可能性があります)

チーム A は、/branches/F で新しい機能 F を開発しています。チーム B は、/branches/P のライブ サイトで発生するパフォーマンスの問題を修正するために別のブランチを開始しました。チーム B が最初に行う必要があるのは、一連のデータベース テーブルおよび/またはファイルの配置方法をリファクタリングすることです。外部ファイルシステム。これにより、チーム A は開発を続行する前に、新しいものの多くをリファクタリングする必要があります。その後、チーム C が入ってきて、別のことをします...そして突然、全員が問題を抱えました。

次に、マージ フェーズが始まります。その後は、誰も TortoiseSVN を使用したくなくなります。

于 2008-10-01T13:58:11.670 に答える