バージョン管理の方法に何か問題がありますか？

私はプログラマーのチームとビジネスアナリストとして仕事をしています。製品のバージョン2.0をリリースしたばかりで、3か月後にリリースされる次のバージョンに取り組んでいます（内部ソフトウェア製品です）。残念ながら、バージョン2.0には修正が必要な問題がいくつかあり、数週間以内に修正を展開する予定です。問題は、まだ作業中であり、さらに3か月間リリースされる予定のない変更を展開したくないことです。

プログラマーは、これを管理する方法は、欠陥のコードのみをチェックインし、新しい拡張機能のコードは、完了するまで開発者のローカルマシンに保持することであると判断しました。テストのためにマシンからローカルビルドを取得する必要があります。彼らがコードをチェックインし、不具合を修正するために別のパッチをプッシュする必要がある場合、それらの機能強化をまだ含めたくないからです。また、同じコードファイルに不具合の修正と機能強化の両方が含まれるという問題もあるため、ローカルでコードファイルをコピーし、バグを修正するために変更を加えてバグをチェックし、その後、彼らが作ったローカルコピー。

かなり複雑に思えます-このタイプのシナリオを処理するより良い方法はありますか？Team Foundation ServerとVisual Studio 2010を使用しています。

V2.0がリリースされたら、「定常状態ブランチ」（TFSではなくPerforceを使用）と呼ばれるものを使用する必要がありました。v2の修正はこのブランチに対して行われ、v3の機能も処理されている間にv3開発ブランチに反映されていました。つまり、v2の欠陥はv3の欠陥にもなります。

変更を開発者のマシンに長期間置くと、統合の悪夢に陥る可能性があります。

そのような問題に対処する方法は複数ありますが、一般に「分岐」タグでカバーされており、それぞれ独自の利点と欠点があります。

しかし、あなたの開発者が選んだアプローチ...うーん、私はそれを口頭で引用して、私が誤解していないことを確認します...

コード...が完了するまで、開発者のローカルマシンに保持されます...

...上記のような方法は、おそらく完全に完全に間違っている唯一の方法です！

私にとって犯罪者と国境を接しているのは、TFSには、優れた、わかりやすいMicrosoft Team Foundation Server Branching Guidanceがあります -さまざまな種類のプロジェクト（HTMLバージョンこちら）。

1. 開発者には、バージョン管理の使用方法に関する基本的な誤解があります。
2. 「正しい」バージョン管理ソフトウェアについての議論に参加しないでください。これは問題ではありません。
3. すべてのコード調整により、問題の修正が難しくなっています。
4. 正しいことをすることに決めた場合、修正中はコードの変更を続行できません。すべての開発を停止し、コードをバージョン管理に入れる必要があります。
5. 開発者は、少なくとも座ってそれについて話すのに十分な痛みを感じている必要があります。
6. すべてのバージョン管理ソフトウェアは、基本的な概念をサポートしています。
   • すべてのコードはバージョン管理リポジトリに格納されます。
   • すべてのコードファイルにはバージョン番号があります。これらの数値は、コードが再チェックインされると自動的に増加します。
   • TAGは、特定のバージョン（および特定のバージョン）のすべてのコードファイルをマークします。したがって、たとえば、ソフトウェアバージョン1リリースにタグを付けることができます。
   • ブランチは、メイントランクからの「方向転換」です。
     • ブランチに加えられたすべての変更は、トランクに影響しません。
     • オプションで、ある時点でブランチの変更をメイントランクにマージして戻すことができます。
     • したがって、「良いもの」を台無しにすることを恐れずに実験することができます。
7. Y'allは、バージョン管理を「信頼の飛躍」と呼んでいます。基本的なルールに従うことで物事がまっすぐになることを信頼してください。経験不足は私たちにそうでないことを考えさせます。
8. これはまともなチュートリアルです。一般的で完全であるため、他の多くのソースを探し回る必要はありません。
   • バージョン管理、より良い説明

編集する

• 作業コンピューターにバージョン管理を配置します。
  • チームの調整なしで今すぐこれを行うことができます
  • チームのバージョン管理でも、これを強くお勧めします
  • チームがGitまたはMercurialを使用している場合、独立したローカルリポジトリを使用しています。それが分散バージョン管理の仕組みです。
  • チームのさまざまなVCソフトウェアを使用できます。私たちのチームはSubversionを使用していますが、私はMercurialをローカルで使用しています。VCソフトウェアメタファイル（「.svn」、「。mg」、隠しフォルダー）は競合しません。

事実上のチームリポジトリとして機能していません。それは、あなた自身の仕事の管理、リファクタリングの努力などのためであり、チームがコードベースのFUBARを続けながら自分自身をCYAするためです。

編集を終了

あなたが説明しているのは、バージョン管理を使用するひどい方法です。リリース2.0用に作成されたブランチ、またはタグまたは何らかの識別子があるはずです。そのようにして、そのリリースへの変更を含めることができ、さらに開発を続けることができます。

この記事では、いくつかのアイデアを提供できます。git念頭に置いて書かれていますが、mercurial同様に機能しなかった理由はありません。これらのどちらも使用していないことに気づきますが、これも修正を検討する必要がある問題です。

クイックアンサー：開発チームは、展開されたコードベースV2.0をメイントランクから分離した状態に保つために、独立した運用ブランチを用意する必要があります。

コードの同期を保つために、すべてのバグ修正を最初にそのブランチで実行し、次にテストして他のブランチに展開する必要があります。

プロジェクトには、Prod、Staging、QA、Dev（UATの場合もあります）のfor health developmentような複数の環境も必要です。これらの環境は、製品リリースに進む前にセットアップする必要があります。

全体として、バグや修正の準備ができていることが、リリースされたアプリケーションをサポートする方法です。

TFSはバージョン管理として言及されていたので、健康開発環境を設定するのに役立つ記事のリストもまとめました。

• 小規模な開発チームでTeam Foundation Serverを実装する
• TFS統合プラットフォームへようこそ！
• TFSガイドを使用したチーム開発
• 開発環境のセットアップ

いいえ、VCSを使用している間はバージョン管理を行っていないためです。

バージョン管理の中心的な概念は、時間の経過に伴う違いを追跡することです。いくつかの違いを記録することを計画していますが、現時点ではほとんどの変更は記録されていません。

他の人が言ったように、ブランチを使用する必要があります。そのセットアップが完了したら、すべての機能変更をチェックインする必要があります（つまり、すべてのキーストロークではなく、バグを修正したり、機能を追加したり、機能を削除したり、ビルドおよび動作するように変更を完了するたびに）必要があります。

私は開発者であり、現在のバージョンの修正用に異なるブランチコードとdbが提供され、拡張機能とその後の連続バージョン用に異なるブランチコードと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" ソリューション全体を検索するコマンドとタイプは、正確な場所、コードが変更されたファイルを見つけ、その部分だけをコミットに使用できる新しいコードを取得するのに役立ちます。