Я являюсь частью организации, которая, к сожалению, использует TFS / TFVC для управления версиями. Моей небольшой команде было поручено провести своего рода «доказательство концепции» с помощью git, но мы должны иметь возможность проталкивать наши изменения в TFS. К счастью, существуют git-tf и git-tfs. Однако наш репозиторий TFS - это единый монолитный репозиторий с более чем 20 различными проектами / приложениями. Правильный способ сделать это в git - сделать каждый проект собственным репозиторием git. Я знаю, что могу проверить отдельный проект из TFS, используя мосты с git-tf, и если бы мы постоянно переходили на git, я бы так и поступил.
Что меня беспокоит, так это то, что нам все еще нужно вернуться к TFVC, если я проверю каждый проект как собственный репозиторий git, не запутается ли TFVC, когда мы вернем изменения, поскольку каждый проект изменяется независимо? То есть, если я проверю Project A из набора изменений 123 и Project B также из 123, внесу изменения в A, а затем верну их обратно в TFVC как набор изменений 124, будет ли TFVC думать, что существует конфликт слияния или другая проблема, когда мы позже внесем изменения в B и подтолкнуть их вверх, так как все это один большой репозиторий в TFVC.
Правильно ли с этим справляется либо git-tf, либо git-tfs? Или мне нужно просто проверить весь репозиторий TFS как единый репозиторий git и работать с ним как есть? Или в этом случае, может быть, было бы лучше проверить различные проекты TFS в одной локальной рабочей области и использовать git для создания репозиториев без использования моста git-tf и проверить изменения обратно в TFS, как если бы они были изменениями, внесенными в рабочее пространство напрямую (в основном игнорируя всю историю git и журналы фиксации и просто используя его для отслеживания локальных изменений)?