Я пишу это с предположением о вашей стратегии:
Ответы, приведенные ниже, имеют изюминку, если предположить, что вы хотите распространять методологию repo-per-sln.«Что лучше для нас - быстро собрать все в одном git-репо и позже разделить или перейти к git по частям?»Это реальный вопрос.Я был только частью 1 миграции, которая сделала всю работу, и усилия по координации были значительными, потому что в пятницу люди пошли домой, используя TFVC, но пришли в понедельник, используя Git.
Я поднял этот вопрос, потому что вы упомянули, что ваш босс
хочет, чтобы [вы] установили надлежащий репозиторий Git для замены существующего репозитория TFVC
Использование «правильного Git-репо» (единственного числа) может изменить способ, которым вам нужно что-то понимать, особенно на фронте CI / CD AzDO.
На (моя версия) ответы:
Как получить только одно из этих решений в одном репозитории Git
Если решения действительно разделены и у вас нет зависимостей от других решений, тогдасоздайте каталог с именем, которое вам нравится для вашего репозитория, и дайте ему хорошую процедуру копирования и вставки.Затем вы можете запустить там git-репо (не забудьте включить хороший файл .gitignore для проектов VS) и зафиксировать начальные изменения.Затем вы можете настроить репозиторий проекта AzDO в качестве удаленного для отправки.
Если вы новичок в Git, вы можете инициировать репо в AzDO и клонировать его локально, а не вручную настраивать AzDO в качестве удаленногодля репо вы создали локально.Тогда вы все еще можете использовать молоток (читай: копировать / вставить), чтобы вставить свой код TFVC в новое git-репо.
Если решения взаимозависимы с ссылками на проекты и сборки, вам нужно действительнодумать о стратегии здесь.В моей последней миграции мы решили использовать пакеты NuGet для доставки компонентов, которые совместно используются несколькими службами или продуктами.В таких случаях вы, вероятно, захотите начать с общего кода.Начните с того, что вам нужно, и реализуйте стратегию доставки, и это даст вам реальное представление о том, что произойдет при миграции.
Какие инструменты следует использоватьв этом случае?
Я склонен использовать Git Bash для большинства подобных вещей, но "каждому свое".Как упомянул @DanielMann, ваш инструмент будет определяться тем, что вам действительно нужно с точки зрения истории.До сих пор я придерживался его мнения во всех моих миграциях.«Пусть прошлое будет прошлым».Эта последняя миграция также предпочла отказаться от локальных конфигураций сборки Team City в пользу чистой реализации AzDO для SC >> CI >> CD.
2) TFS имеет три ветви: dev,main и master (которые являются родителями папок решения).Как я могу получить только одну из этих веток, которая будет перенесена в Git (т.е. я просто хочу, чтобы Мастер был перенесен)?Нужно ли включать все ветви?
Я собираюсь изменить порядок этих двух вопросов:
Нужно ли включать все ветви?
Нет.TFVC отслеживает файлы, поэтому каждая ветвь имеет свой собственный фрагмент файловой системы.
2) TFS имеет три ветви: dev, main и master (которые являются родителями папок решения).Как я могу получить только одну из этих веток, которая будет перенесена в Git (т.е. я просто хочу, чтобы Мастер был перенесен)?
Снова, используйте молот.Вы должны создать новую область вашей локальной файловой системы для представления репозитория.Например: мой контейнер репо c:/src/, тогда у меня есть каталоги, представляющие каждый отдельный репо c:src/r1/ c:src/r2/ ect.(примечание: мои имена намного лучше, чем в примере).Получив это, возьмите последнюю информацию в нужной ветке TFVC и отбейте ее.
Возможная головная боль
Убедитесь, что вы можете заставить других разработчиков прекратить вносить изменения в код, который вы переносите.Если вы также настраиваете конвейер AzDO CI / CD, вы можете в конечном итоге внести изменения в проекты, чтобы это работало.Если разработчики все еще меняют исходный код, над которым вы работаете, вы захотите повторить ваши изменения в TFVC, чтобы они могли писать поверх них, иначе вы будете в аду слияния, когда попытаетесь вбить новые изменения обратно в git.