バージョン管理の方法に何か問題がありますか？
私はプログラマーのチームとビジネスアナリストとして働いています。製品のバージョン2.0をリリースしたばかりで、3か月後にリリースされる次のバージョンに取り組んでいます（これは内部ソフトウェア製品です）。残念ながら、バージョン2.0には修正が必要な問題がいくつかあります。これらの修正は数週間で展開する予定です。問題は、まだ作業中で、今後3か月間リリースされる予定のない変更を展開したくないことです。
プログラマーは、これを管理する方法は、欠陥のコードのみをチェックインし、新しい拡張機能のコードは、完了するまで開発者のローカルマシンに保持することであると決定しました。彼らがコードをチェックインし、欠陥を修正するために別のパッチをプッシュアウトする必要がある場合、これらの拡張機能をまだ含めたくないので、私は彼らのマシンからローカルビルドを取得してテストする必要があります。同じコードファイルに欠陥修正と拡張機能の両方が含まれているため、コードファイルをローカルにコピーし、変更を加えてバグを修正し、チェックインしてから、拡張機能の作業を再開する必要があるという問題もあります。彼らが作ったローカルコピー。
それはかなり複雑です-このタイプのシナリオを処理するより良い方法はありますか？ Team Foundation ServerとVisual Studio 2010を使用しています。
V2.0は、リリースされると、「定常状態ブランチ」（TFSではなくPerforceを使用しました）と呼ばれるものが作成されているはずです。 v2の修正はこのブランチに対して行われ、v3機能も処理されている間にv3開発ブランチに反映されます。つまり、v2の欠陥はv3の欠陥にもつながります。
変更を長期間にわたって開発者のマシンに常駐させると、統合に悪夢が生じる可能性があります。
まあ、そのような問題に対処するために 複数の方法 があり、一般的に 'branching'タグ でカバーされており、それぞれ独自の利点と欠点があります。
しかし、開発者が選択したアプローチ...誤解しないように、口頭で引用します...
コード...完了するまで、開発者のローカルマシンに保持されます...
...上記の方法はおそらく完全に完全に間違っている唯一のものです！
私にとって犯罪との境界をなすのは、TFSには優れた、理解しやすい優れた機能があるということです Microsoft Team Foundation Server分岐ガイダンス -分岐戦略の推奨事項がすべての人のために注意深く調整および説明された巨大で詳細なドキュメント種類の異なるプロジェクト（ HTMLバージョンはこちら ）。
- 開発者は、バージョン管理の使用方法について根本的な誤解を持っています。
- 「正しい」バージョン管理ソフトウェアについての議論に入らないでください。これは問題ではありません。
- Tweakのすべてのコードは、問題の修正を難しくしています。
- すべての人が正しいことを行うと決めた場合、修正を行っている間はコードの変更を続けることができません。すべての開発を停止し、コードをバージョン管理に入れなければなりません。
- 開発者のmust少なくとも座ってそれについて話すのに十分な痛みを感じていること。
- すべてのバージョン管理ソフトウェアは、基本的な概念をサポートしています。
- すべてのコードはバージョン管理リポジトリに入ります。
- すべてのコードファイルにはバージョン番号があります。これらの数値は、コードが再チェックインされると自動的に増加します。
- タグは、特定のバージョン（および特定のバージョン）のすべてのコードファイルをマークします。したがって、たとえばソフトウェアバージョン1リリースにタグを付けることができます。
- ブランチはメイントランク。からの "方向転換"です。
- ブランチに加えられたすべての変更は、トランクには影響しません。
- オプションでmergeブランチの変更をある時点でメイントランクに戻すことができます。
- したがって、「良いもの」を台無しにすることを恐れずに実験できます。
- 私が言うように、Y'allはバージョン管理を「信仰の飛躍」を得なければなりません。基本的なルールに従うことは物事をまっすぐに保つことを信頼します。未経験は私たちに別のことを考えさせます、私を信頼してください。
- これはまともなチュートリアルです。それは一般的で十分なため、他の多くのソースを精査する必要はありません
edit
- 仕事用のコンピューターにバージョン管理を置きます。
- チームの調整なしで今すぐこれを行うことができます
- チームのバージョン管理があっても、これを強くお勧めします
- チームがGitまたはMercurialを使用している場合は、独立したローカルリポジトリを使用しています。これが、分散バージョン管理の仕組みです。
- 別のVCチームのソフトウェアを使用できます。私たちのチームはSubversionを使用しています。私はMercurialをローカルで使用しています。VCソフトウェアメタファイル（ ".svn"、 "。 mg "、隠しフォルダ）は競合しません。
あなたは事実上のチームリポジトリとして機能していません。これは、自分の作業の管理、リファクタリングの作業などを行い、チームがコードベースをFUBARし続けるときに自分をCYAするためのものです。
編集を終了
あなたが説明しているのは、バージョン管理を使用する恐ろしい方法です。リリース2.0用に作成されたブランチ、またはタグや何らかの識別子があったはずです。そうすれば、そのリリースへの変更を封じ込め、より多くの開発を続けることができます。
この記事はいくつかのアイデアを提供します。gitを念頭に置いて書かれていますが、Mercurialでも機能しない理由はありません。これらのどちらも使用していないようですが、これも修正を検討する必要がある問題です。
簡単な回答：開発チームは、展開を維持するために個別の本番ブランチを保持する必要がありますMainトランクとは別のコードベースV2.0。
すべてのバグ修正は、最初にそのブランチで実行され、次にテストされ、他のブランチに順番にデプロイされる必要がありますコードを同期させる。
プロジェクトにはいくつかの環境があるはずですfor health development likeProd、Staging、QA、Dev（時々UAT）。これらの環境は、本番リリースに進む前にセットアップする必要があります。
全体として、バグや修正の準備ができていることがリリースされたアプリケーションをサポートする方法です。
TFSがバージョン管理として言及されたので、健康開発環境を設定するのに役立つ記事のリストもまとめました。
いいえ、VCSを使用している間はバージョン管理を行っていないためです。
バージョン管理の中心的な概念は、時間の経過に伴う違いを追跡することです。いくつかの違いを記録することを計画していますが、現時点ではほとんどの変更は記録されていません。
他の人が言ったように、ブランチを使うべきです。そのセットアップが完了したら、すべての機能の変更をチェックインする必要があります（つまり、すべてのキーストロークではなく、バグを修正、機能を追加、機能を削除するか、変更が完了してビルドと機能が維持されるようにします）。
私は開発者です。現在のバージョンの修正用に別のブランチコードとdbが与えられ、機能拡張とその後のバージョン用に別のコードが与えられます。
修正が完了すると、それらは本番環境にマージされて展開され、新しいブランチを取得して機能拡張に戻ります。
さらに、現在のバージョンに10個の修正がある場合のような慣習に従います
私は
//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"
他の修正についても同様に、変更または修正のために追加するすべての行に対してこれを行います。そして、比較してコミットするだけです。同様に、同じブランチで並列処理を行っている場合、使用できます
//Start Enhancement -1, Branch No-"ABC"
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC"
Ctrl+Shift+Fコマンドと入力//Start Iteration 2, Fix No-1, Branch No-"ABC"ソリューション全体を検索すると、正確な場所、コードが変更されたファイル、およびコミットに使用できるその部分のみを新鮮なコードを取得するのに役立ちます。