Перенесення коду з tfs на git, SavePearlHarbor

Ще одна копія хабора

Головне меню

Навігація за записами

Перенесення коду з tfs на git

Завдання:перенести розробку build на git, зберігши у своїй історію змін.Ризики

  • Не всю історію вдасться перенести: якщо ви активно переміщали ваш код, іноді частина губиться;
  • Код доведеться перекласти на гілки руками;
  • Можливо, доведеться деякий час «жити» паралельно на двох системах контролю версій;
  • Якщо при build ви використовували більше одного проекту, то доведеться підключити їх як submodules або вигадувати інші способи підключення залежностей (nuget, наприклад, .net, gem в ruby ​​тощо);
  • Доведеться перенести як код, а й build.

Перед початком міграції коду.

Перед тим, як переноситимете репозиторій, рекомендую погасити технічні борги в плані version control: видалити мертві гілки; смержити те, що потрібно смержити; видалити непотрібний/невикористовується код, файли, які не повинні бути в source control, в принципі (проміжні етапи компіляції, індекси resharper і т.п.). Це краще зробити TFS, т.к. тягнути це у GIT все одно сенсу не має. Що менше сутностей для перенесення, то краще. Заздалегідь варто подумати і про те, як у git буде цей переносний код розкладений. Наприклад, TFS дозволяв у рамках одного TFS Project вести хоч сотню проектів у сенсі коду, і кожним з них керувати окремо, робити комміти в окрему папку тощо. Git такого не дозволить. Принаймні управління різними проектами в рамках одного репозиторію окремо тут неможливе.

Починаємо міграцію

Git-TF - це основна утиліта, яка, виключаючи мозок і знання про код, знадобиться приміграції.

Установка Git-TF

Качаємо утиліту міграції. Вона на java. Відкривши її, читаємо документацію з налаштування. Це не довго, раджу витратити на це кілька хвилин.

Загалом вона тривіальна. Поставити java, прописати шляхи до змінної оточення на java і на команду Git-TF. Java потрібна, щоб утиліту можна було запустити і на Windows не машинах.

Clone коду

Після завершення налаштування виконуємо клонування з консолі. Синтаксис:git tf clone tfs-server:8080/tfs/*Collection $/Project –deep–deep означає клонування з історією, а не тільки останній зліпок коду.

Після закінчення викачування кодів в home каталозі (C:/users/myuser) буде перебувати проект з ім'ям, що відповідає проекту TFS.

При цьому буде перенесено всю історію, яка була в цьому репозиторії. Кожен коміт буде позначений тегом. Тег - це номер комміта в TFS (дуже допомагає, якщо потрібно подивитися, як все було до git).

Варіанти міграції

Концепції системи зберігання коду в TFS та GIT різні. Тому сконвертувати однією командою зі збереженням гілок TFVC в Git репозиторії не так просто. Тут є ще другий момент: це буде перманентна міграція або якийсь час ви готові працювати. Залежно від цього я виділив би такі варіанти міграції:

Перманентно №1

Git-TF може скопіювати весь рапозиторій, і буде одна гілка в git-master. Всі TFS гілки будуть разом як папки. Вам доведеться руками створити гілки і вручну розкласти в них код так, як вам потрібно.

Проблема тут очевидна - до точки поділу коду Git всі зміни лежать скопом. Вже потім доведеться приводити проект до нормального для Git виду.

Перманентно №2

Використовуючи GIT TF, можна витягнути всі потрібні гілки і зробити їх гілками-сиротами (orphan), і вже по необхідності в git робити merge. Тут проблема діаметрально протилежна — до точки злиття коди різних гілок незалежні.

Чи не перманентно

Якщо ви готові деякий час жити частково в Git, частково TFVC, цей варіант для вас. Міграція гілки main з TFVC в ветку main на Git. Далі вже бранчуємося від цієї перенесеної гілки. У міру готовності гілок в TFVC до злиття робити merge всередині TFVC, а потім робити Git TF pull з гілки main TFVC в Git main. Таким чином, ми заберемо різницю між коммітами у TFVC та Git. Далі робимо rebase за потребою. Проблема теж очевидна — жити у 2 різних project якийсь час із 2 різними системами контролю версій. Можна дуже добре розійтися на рівні коду.

Загальні моменти для всіх варіантів

Після того, як ви локально отримали код та його історію, потрібно зробити кілька речей: Створити в новому TFS projectCollection (це опціонально) і всі projects. Не буду на цьому звертати уваги — можна погуглити чи прочитати мою статтю про міграцію SVN до Git-TFS.

Push на remote

Далі додати новий віддалений репозиторій (remote) зробити туди push. Обов'язково разом із tags, щоб потім можна було шукати відповідність.

Розклад коду, у випадку Перманентно 1

У моєму випадку все перенесення розтягнулося на 2 дні. Проект було поділено на 12 підпроектів, т.к. Саме стільки різних логічних проектів у ньому жило, і все це винесено в окремий проектколекції.

Основним обмежуючим фактором було:

  • Наявність певного безладдя у репозиторії;
  • Необхідність самомустворити та перевірити на збирання всі гілки;
  • Підключити submodules;
  • Створити бінарні гілки у репозиторіях із кодом;
  • Нерозуміння в одному з проектів яка гілка жива, яка не жива.

Все це стосується не методу, а проекту в цілому.

Merge, Git TF pull, Rebase у разі не перманентної міграції

Якщо схематично малювати, буде приблизно так.

За такої міграції нам пощастило - ніяких submodules не було, т.ч. коди ми перекладали один на один. Наявність старого коду, мертвих гілок, звичайно, ускладнило життя, але мертві гілки ми не переносили і, отже, у Git код був чистіший.

Обмеження історії:

Git-TF нічого не знає про інші проекти, крім того, що ви вказали. Тобто. якщо ваш код колись був в іншому project collection або іншому project, то в TFS комміти з них не побачите - тільки ті, які в поточному проекті (файли при цьому звичайно будуть на диску). Як ви бачили історію в TFS, так само ви її побачите у Git. Приклад: ви зробили move шматка коду з одного TFS project в інший. Тоді командаgit tf clone tfs:8080/tfs/DefaultCollection $/TargetProjects —deepвитягне лише останній коміт, без історії. Якщо move був зроблений нещодавно, то можна забрати історію зі старого проекту, вказавши останній перед move комміт. Якщо ж ці зміни були зроблені давно, то це буде вкрай важко - витягнути історію, т.е. до. потрібно буде зробити багато ручних маніпуляцій.

Не наступайте на наші граблі:

  • "Вирішили переходити на Git, переходьте на Git", - ця фраза здаєтьсябанальною, але якщо переходити на Git по півроку, то в цей час виникне дуже багато проблем, які сильно виснажують усім нерви.
  • Git – це source control. Не треба намагатися разом із Git відразу поміняти build систему та процеси розробки. Зробіть спочатку одне, потім інше. Саме через те, що Git розглядався в контексті зміни процесу розробки-тестування-впровадження-супроводу в однієї з команд дуже довго триває процес міграції. Вже півроку…
  • Переконайтеся, що всі розробники хоча б мінімальної практики роботи з Git отримали до початку. Інакше може настати момент, коли "ніколи думати, треба робити". А раптом виявиться, що людина не знає, як свій код об'єднати з іншої гілки і викласти на remote repository.