3

私はGit-tfを使用して（明らかに）TFSをスキップし、オフラインで作業して読み取り専用とそのすべての調整を回避できるようにしています...今..ドライブDと言うためにtfsプロジェクトのクローンを作成し始めました：その後、再度クローンを作成しましたドライブcから：（私はそこで偏執的だったと思います）

私の現在のワークフローは、(レポ c: で) 変更をレポ D: にコミットしてから、チェックインを TFS にプッシュすることです。

正常に動作しますが、面倒になり、ワークフローを複雑にしすぎていると思います

何が最高でしょうか？

レポ c: を構成して、TFS を直接指すようにすることはできますか ... ネイティブの git origin (レポ d:) を削除します レポ d: を c: にコピーして続行します (試してみましたが、ローカルでは正常に動作しますが、コミットしませんでしたTFS にまだ変更がある場合) レポ c: を ORIGIN に昇格させ (D: のように)、そこから変更を TFS にプッシュし続けることはできますか (git-tf config の後) ? ...このプロモートについてはよくわかりません...

また、プロジェクト（C＃vs2012のように）を念頭に置いて、その大きなプロジェクトはそれほど簡単ではありません再構成してビルドします）コピープロセスを待つことさえ言及しません:) . その他の提案はありますか？

4

1 に答える 1

1

C:TFSを直接指すようにリポジトリを構成することはできません。リポジトリには、リポジトリD:をフェッチ/クローンしたときに作成されたTFSチェンジセットマッピングへのgitcommitに関するデータが含まれています。このデータgit-tfがないと、TFSチェンジセットを作成するために、最後にフェッチしたチェンジセットと現在のコミットの間にデルタを構築できません。

にコピーD:すると、gitリポジトリに保存されているメタデータC:がコピーされるため、問題ありません。git-tf

C:「昇格」とはどういう意味かわかりませんD:。C:からクローンをD:作成した場合は、変更を加えてからプッシュバックしてからプッシュバックできD:ますgit-tf checkin。新しいgitコミットがどこから来たのかは実際には問題ではありません。HEAD最新のTFSチェンジセットから作成されたコミットの子または孫であるコミットを指す場合git-tf、違いの新しいチェンジセットを構築できます。

于 2012-12-13T16:38:54.803 に答える