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

    В один прекрасний день, наш TFS2012 був оновлений до TFS2013.
Разом з TFS2013 у нас з'явилася можливість, залишаючись у рамках звичного інтерфейсу адміністрування та менеджменту прав, перейти на розподілену source control git. (Про плюс і мінуси розподіленого source control сказано вже стільки, що повторювати не варто, тому холіваров вже було багато.)
 
 Задача: перенести розробку build на git, зберігши при цьому історію змін.
 Ризики
 
 
     
  • Чи не всю історію вдасться перенести: якщо ви активно переміщали ваш код, іноді частина втрачається;
  •  
  • Код доведеться переразложіть на гілки руками;
  •  
  • Можливо, доведеться деякий час «жити» паралельно на 2 системах контролю версій;
  •  
  • Якщо при 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, щоб потім можна було шукати відповідність.
 У GitExtensions це тут
 
 

Розкладання коду, у разі Перманентно 1

У моєму випадку, весь перенесення розтягнувся на 2 дні.
Проект був розділений на 12 підпроектів, т.к. саме стільки різних логічних проектів в ньому жило, і все це винесено в окремий projectCollection.
 
 Вийшло ось так:
 
Основним обмежуючим фактором було:
 
 
     
  • Наявність певного безладу в репозиторії;
  •  
  • Необхідність самому створити і перевірити на збирання все гілки;
  •  
  • Підключити submodules;
  •  
  • Створити бінарні гілки в репозиторіях з кодом;
  •  
  • Нерозуміння в одному з проектів яка гілка жива, яка НЕ ​​жива.
  •  
Все це відноситься не до методу, а до проекту в цілому.
 
 
Merge, Git TF pull, Rebase в разі не перманентної міграції
Якщо схематично малювати, то буде приблизно так.
 Крок 1
 Крок 2
 Крок 3
 Крок 4
 Крок 5
 Крок 6
 
При такій міграції нам пощастило — ніяких 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 tf clone tfs : 8080/tfs/DefaultCollection $ / SourceProjects — deep — version = 57012
Якщо ж ці зміни були зроблені давно, то це буде вкрай важко — витягнути історію, тому що потрібно буде виконати багато ручних маніпуляцій.
 
 
не стати на наші граблі:
 
     
  • "Вирішили переходити на Git, переходите на Git", — ця фраза здається банальною, але якщо переходити на Git по півроку, то в цей час виникне занадто багато проблем, які сильно вимотають всім нерви.
  •  
  • Git — це source control. Не треба намагатися разом з Git відразу поміняти build систему і процеси розробки. Зробіть спочатку одне, потім інше. Саме через те, що Git розглядався в контексті зміни процесу розробки-тестування-впровадження-супроводу у однієї з команд дуже довго йде процес міграції. Вже півроку…
  •  
  • Переконайтеся, що всі розробники хоча б мінімальну практику роботи з Git отримали до початку. Інакше може настати момент, коли "ніколи думати, треба робити". А тут раптом виявиться, що людина не знає, як свій код об'єднати з іншого гілки і викласти на remote repository.
  •  
 
P.S.
Є у мене невеликий проект GitQuiz (тестові приклади, відео як їх виконати).
Дуже допомагає для навчання розробників, у яких є деякі теоретичні знання по роботі з розподіленими системами зберігання вихідних кодів, але немає практичного досвіду. Я його на своїх колегах опробірованних.
 Ну а зовсім для профі, можна мені з цим проектом допомогти, є набір завдань , до яких у мене поки руки не дійшли.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.