現在、作業が行われており、新しいハードウェアに移植されているレガシー コードベースがあるとします。現在、バージョン管理はそれだけで処理されており、コードで行われるすべての作業は、一度に 1 つずつ CM に変換される一連の zip パッケージ (およびそのテスト) を介して行われます。リリースの準備が整うと、競合が解決された前のリリースの上に個々の変更がダンプされ、そのコードがこのリリースのリグレッシブ テスト スイートを通じて実行され、それが新しいリリースになります。
私たちの CMS には現在、プルダウンできるメジャー リリースだけがあり、個々の変更が利用可能です。新しいメンテナンス サイクルのために TFS-Git ハイブリッドに移行することについて話しているのは、コードがコンパイルされ、変更が管理されていた古いシステムを捨てることができるからです (開発リポジトリとして Git を使用したいのですが、 '私たちは常にTFSを使用してきました.これは私たちが引き続き使用するものです. 私はすべてのメジャー リリースを取得し、個人用リポジトリにコミットとして設定しました。これは簡単に実行できます。
変更を追跡する主要な方法として、Word ドキュメントに添付されたコード ファイルではなく、Git または TFS を使用することを推奨したい場合は、それが可能であることを実証する必要があるでしょう。すべての変更に対して 1 つのベースラインから離れることはできず、変更を追跡する唯一の方法は、実際に変更されたファイルをパッケージとして提出することだと聞いています (それについて頭を悩ませることはできません)。実際、多くの人がプロセスを変更できない理由についてさまざまなことを言っていますが、それは新しいハードウェアに関係するものであり、私は解決策が中途半端ではないことを望みます.
これまでのところ、VMS CMS からすべてのメジャー リリースを取得し、バナー ファイル (コメントのみのファイル、SDD を書くための方法) を CMS から切り替えたときに TFS から取得し、それらの間の一連のイベントを決定しました。それらを作成し、それぞれがリリースごとにタグ付けされた 1 つのマスターに一連のコミットを行います (実際には 2 つの CMS リリースの間にある TFS のバナー バージョンのコミットを保存します。使用するソース参照ドライブは、リリースのバナーがキャプチャされなかったことを示しています)。 .
戻って、タグ付けされた各コミットからブランチを作成したいのですが、正しいですか? 次に、それぞれが以前のリリースを親として持つようにリベースしますか? その時点で、変更履歴をキャプチャできることを示すために、子リリース用にアーカイブした各変更パッケージのリリースから分岐します。次に、すべての変更パッケージ ブランチの子リリースをリベースします。良くも悪くもそれが私たちのやり方だからです。
だから私のツリーは現在これだけです...
*baseline
|
|
*release1
|
|
*release2
ツリーはこんな感じ…。
*baseline
/ | \
/ | \
*chg0-0 *chg0-1 ...chg0-n
\ | /
\ | /
*release1
/ | \
/ | \
*chg1-0 *chg1-1 ...chg1-n
\ | /
\ | /
*release2
持っているものを好きなものに作り変えることはできますか？複数の親のマージとしてコミットをリベースできますか? 自宅で設定したテストレポにそのような履歴を挿入できるようですが、一度に統合のステップを理解していません。その後、一度に1つずつマージすることは、おそらくまだまずまずです。
仕事でこのような「ゴールドブリック」をする時間はあまりなく、現在は機能的なパッケージを書くのに忙しいです。ネットワーク上の私の共有を誰かに指摘するだけでなく、定期的に「コミット」を行わなければならないようなコラボレーションを望んでいます。そのためには、ソフトウェア コンポーネントごとに一連の Beyond Compare セッションを設定し、変更されたファイルと差分をダンプします。そこの。一度にコードに取り組んでいるのは数人だけですが、彼らはこの種のツールを作成しています...