9.1 Git and Other Systems - Git як клієнт

Базова команда Git для всіх команд мосту Subversion — git svn. Вона приймає доволі багато команд, отже ми покажемо найпоширеніші під час розгляду декількох простих процесів роботи.

Важливо зазначити, що коли ви використовуєте git svn, то взаємодієте зі Subversion, який є системою, що працює геть іншим чином, порівняно з Git. Хоча ви можете виконувати локальне галуження та зливання, зазвичай найкраще зберігати історію якомога лінійнішою за допомогою перебазування, та уникати чогось на кшталт взаємодії з віддаленим сховищем Git.

Не переписуйте історії та не намагайтесь знову надіслати зміни, та не надсилайте до паралельного сховища Git для взаємодії зі співробітниками, які використовують Git. Subversion може мати лише єдину лінійну історію, та заплутати його дуже легко. Якщо ви працюєте в команді, і дехто використовує SVN, а інші — Git, переконайтесь, що всі використовують сервер SVN для взаємодії — це зробить ваше життя легшим.

Задля демонстрації цього функціоналу, вам потрібне звичайне сховище SVN, до якого у вас є доступ на запис. Якщо бажаєте виконувати подальші приклади, вам треба створити копію якогось тестового SVN сховища з правом на запис. Щоб зробити це легко, ви можете використати інструмент під назвою svnsync, який постачається разом зі Subversion.

Щоб схоплювати думку, вам спочатку треба створити локальне сховище Subversion:

Потім, дозволити всім користувачам змінювати revprops — це просто зробити, якщо додати скрипт pre-revprop-change, який завжди повертає 0:

Тепер ви можете синхронізувати цей проект на вашій локальній машині — для цього треба викликати svnsync init з параметрами до якого'' та з якого'' сховища синхронізувати.

Це налаштовує властивості (properties) для виконання синхронізації. Потім треба зробити клонування коду, виконавши

Хоча ця операція може потребувати лише кілька хвилин, якщо ви спробуєте скопіювати оригінальне сховище до іншого віддаленого, замість локального, процес займе близько години, навіть якщо там менше ніж 100 комітів. Subversion має клонувати одну ревізію за раз та потім надсилати її до іншого сховища — це химерно неефективно, проте це єдиний простий спосіб.

Тепер, коли у вас є сховище Subversion з доступом на запис, ви можете прослідкувати за типовим процесом роботи. Ви почнете з команди git svn clone, яка імпортує весь репозиторій Subversion до локального сховища Git. Памʼятайте: якщо ви імпортуєте зі справжнього розгорнутого (hosted) сховища Subversion, то маєте замінити file:///tmp/test-svn на URL вашого репозиторія Subversion:

Це еквівалентно виклику двох команд — git svn init та потім git svn fetch — з URL, який ви надали. Це може бути довгим процесом. Якщо, наприклад, тестовий проект має лише приблизно 75 комітів та невеликий за розміром код, Git все одно має отримати кожну версію, по одній за раз, та створювати коміти для кожної. Для проекту зі сотнями чи тисячами комітів, це може дійсно потребувати годин або навіть днів, щоб завершитись.

Частина -T trunk -b branches -t tags каже Git, що цей репозиторій Subversion розташовує гілки та теґи як заведено. Якщо у вас trunk, гілки чи теґи називаються інакше, ви можете змінити ці опції. Через те, що ця частина дуже розповсюджена, її всю можна замінити на -s, що означає стандартне розташування та означає всі ці опції. Наступна команда еквівалентна попередній:

Наразі, у вас має бути працюючий репозиторій Git, який містить імпортовані гілки та теґи:

Завважте, цей інструмент працює з теґами Subversion як з віддаленими посиланнями. Подивімося прискіпливіше за допомогою кухонної команди Git show-ref:

Git такого не робить, коли клонує з Git сервера; ось як сховище з теґами виглядає відразу після клонування:

Git отримує теґи напряму до refs/tags, замість того, щоб працювати з ними, як з віддаленими гілками.

Тепер, коли у вас є робоча тека, ви можете попрацювати над проектом на надіслати свої коміти назад до першоджерела, використовуючи Git фактично як клієнт SVN. Якщо ви відредагували один з файлів та зберегли його в коміті, то маєте коміт, що існує в Git локально, проте не існує на сервері Subversion:

Далі, вам треба надіслати свої зміни до першоджерела. Завважте, як це змінює спосіб роботи з Subversion — ви можете створити декілька комітів локально, та лише потім надіслати їх всіх разом до сервера Subversion. Щоб надіслати до сервера Subversion, треба виконати команду git svn dcommit:

Вона бере всі коміти, які ви створили поверху коду з сервера Subversion, робить коміт Subversion для кожного, та потім переписує ваші локальні коміти Git, щоб додати до них унікальний ідентифікатор. Це важливо, оскільки означає, що всі SHA-1 суми ваших комітів зміняться. Частково через це, робота з віддаленою версію проекту, яка працює на Git, та одночасно працювати з сервером Subversion, не є гарною ідеєю. Якщо ви подивитесь на останній коміт, то побачите новий доданий git-svn-id:

Зверніть увагу, що раніше сума SHA-1 починалася з 4af61fd, а після коміту починається з 95e0222. Якщо ви бажаєте надсилати зміни й до сервера Git, і до сервера Subversion, то маєте спочатку надіслати (dcommit) до Subversion, оскільки ця дія змінює дані комітів.

Якщо ви працюєте з іншими розробниками, то колись хтось з вас надішле зміни, потім хтось інших спробує надіслати зміни, які призводять до конфлікту. Ця зміна буде відхилена, доки ви не зіллєте їхню роботу. З git svn, це виглядає так:

Щоб розвʼязати цю проблему, ви можете виконати git svn rebase, який отримує будь-які зміни на сервері, яких у вас покищо немає, та перебазовує всю роботу, яка у вас є поверху того, що є на сервері:

Тепер, вся ваша робота знаходиться поверху того, що є на сервері Subversion, отже ви можете успішно зробити dcommit:

Зверніть увагу, що на відміну від Git, який вимагає від вас зливати роботу з першоджерела, якої у вас немає локально перед надсиланням, git svn вимагає від вас цього лише якщо зміни конфліктують (так само, як працює Subversion). Якщо хтось інший надішле зміну до одного файлу, а потім ви надішлете зміну до іншого файлу, ваш dcommit спрацює без проблем:

Це важливо памʼятати, адже призводить до стану проекту, якого не існувало на жодному з клієнтів перед надсиланням. Якщо зміни несумісні, хоча й не конфліктують, ви можете отримати проблеми, які важко виявити. Це відрізняється від користування сервером Git — у Git ви можете повністю перевірити стан на клієнтській системі перед його публікацією, а в SVN, ви навіть не можете бути певні, що стан прямо перед комітом та після нього однакові.

Вам також варто виконати наступну команду, щоб отримати зміни зі сервера Subversion, якщо ви не готові створити коміт. Ви можете виконати git svn fetch, щоб взяти нові дані, проте git svn rebase і отримує дані, і оновлює ваші локальні коміти.

Виконуйте git svn rebase подеколи, щоб переконатися, що ваш код завжди синхронізовано. Втім, вам треба переконатися, що робоча директорія чиста перед виконанням цієї команди. Якщо у вас є локальні зміни, то треба або сховати їх, або тимчасово створити з них коміт перед виконанням git svn rebase — інакше, команда зупиниться, якщо побачить, що перебазування призведе до конфліктів злиття.

Коли ви звикаєте до процесу роботи Git, ви, вірогідно, створюєте тематичні гілки, працюєте в них, а потім зливаєте їх. Якщо ви надсилаєте до сервера Subversion командою git svn, то можливо ліпше перебазувати вашу роботу поверху однієї гілки замість того, щоб зливати гілки разом. Причина надати перевагу перебазуванню в тому, що Subversion має лінійну історію, та не працює зі зливаннями, як Git, отже git svn слідує лише за першими батьками, коли перетворює відбитки на коміти Subversion.

Припустімо, що ваша історія виглядає наступним чином: ви створили гілку experiment, зробили два коміти, а потім злили їх назад до master. Коли ви зробите dcommit, то побачите щось таке:

Виконання dcommit на гілці зі злитою історією працює успішно, окрім того, що, якщо подивитись на історію проекту Git, то виявиться, що жоден з комітів, створених у гілці experiment, не переписано — натомість, усі ці зміни зʼявляються у версії SVN як єдиний коміт злиття.

Коли хтось зробить клон цієї праці, усе, що вони побачать — коміт зливання з усіма змінами в ньому, ніби ви виконали git merge --squash; вони не побачать дані про окремі коміти - коли вони були створені чи звідки взялися.

Галуження Subversion не таке, як в Git: якщо ви можете уникнути його використання, то, напевно, найкраще це зробити. Втім, ви можете створювати й надсилати коміти до гілок Subversion за допомогою git svn.

Щоб створити нову гілку Subversion, ви можете виконати git svn branch [назва-нової-гілки]:

Це рівнозначно команді Subversion svn copy trunk branches/opera та виконується на сервері Subversion. Важливо зазначити, що це не переключає вас до нової гілки; якщо ви зараз створите коміт, цей коміт піде до гілки trunk на сервері, а не до opera.

Git визначає, до якої гілки dcommit має надсилати ваші зміни наступним чином: знаходить верхівку будь-якої з ваших гілок Subversion в історії — у вас має бути лише одна, та це має бути останній коміт з git-svn-id в історії вашої поточної гілки.

Якщо ви бажаєте працювати більш ніж з однією гілкою одночасно, то можете налаштувати локальні гілки робити dcomit до окремих гілок Subversion, якщо почнете їх за допомогою імпортування коміту з потрібної гілки Subversion. Якщо вам потрібна гілка opera, над якою ви зможете працювати окремо, то можете виконати

Тепер, якщо ви бажаєте злити свою гілку opera до trunk (ваша гілка master), то можете це зробити звичайним git merge. Проте, ви маєте зробити повідомлення коміту змістовним (за допомогою -m), інакше злиття просто напише ``Merge branch opera'' замість чогось корисного.

Памʼятайте: хоча ви використовуєте git merge для цієї операції, і зливання напевно буде набагато легшим, ніж було б у Subversion (адже Git автоматично знайде відповідну базу для злиття), це не звичайний коміт злиття Git. Ви маєте надіслати ці дані назад до серверу Subversion, який не може впоратись з комітом, який має більше одного батька; отже, після того, як ви його надішлете, він буде виглядати, як коміт, який зварив у собі всю роботу з іншої гілки. Після зливання однієї гілки в іншу, ви не зможете легко повернутись назад та продовжити роботу в тій гілці, як зазвичай у Git. Команда dcommit, яку ви виконуєте, стирає будь-яку інформацію про зливання гілки, отже наступні визначення бази для зливання будуть хибними — dcommit призводить до того, що результат вашого git merge виглядає так, ніби ви виконали git merge --squash. На жаль, не існує доладного способу уникнути цієї ситуації — Subversion не може зберігати цю інформацію, отже ви завжди будете окалічені цими обмеженнями, доки використовуєте його як свій сервер. Щоб уникнути проблем, варто вилучити локальну гілку (у даному випадку, opera) після зливання її до trunk.

Набір інструментів git svn пропонує чимало команд, щоб полегшити перехід до Git, для чого надає деякий функціонал, схожий на те, що було в Subversion. Ось декілька команд, які надають вам те, що пропонував Subversion.

Інструменти git svn корисні, якщо ви захрясли зі сервером Subversion, чи іншим чином потрапили в середовище розробки, яке вимагає працюючого сервера Subversion. Втім, ви маєте вважати їх покаліченим Git, інакше можете зіткнутися з проблемами переходу, які можуть спантеличити вас чи ваших співробітників. Щоб уникнути проблем, намагайтесь слідувати таким порадам:

Якщо ви слідуватимете цим порадам, працю зі сервером Subversion буде легше витримати. Втім, якщо є можливість перейти на справжній сервер Git, то це надасть вашій команді набагато більше переваг.

Для початку, вам потрібно встановити git-remote-hg. Для цього скопіюйте файл до директорії, що є у вашому PATH, наприклад:

…припускаючи, що ~/bin включений у ваш $PATH. Git-remote-hg має ще одну залежність: бібліотеку mercurial для Python. Якщо у вас встановлено Python, просто виконайте:

(Якщо ж у вас не встановлено Python, перейдіть за посиланням https://www.python.org/ і спочатку встановіть його.)

І останнє, що вам знадобиться, це клієнт Mercurial. Перейдіть за посиланням https://www.mercurial-scm.org/ і встановіть його, якщо ви цього ще не зробили.

Тепер ви готові побачити магію. Усе, що вам необхідно, це Mercurial-репозиторій, у який ви можете надсилати зміни. На щастя, так можна працювати з кожним Mercurial-репозиторієм, тому ми скористаємось репозиторієм "hello world", який використовується для вивчення Mercurial:

Тепер, коли в нас є "серверний" репозиторій, ми можемо розглянути типові способи роботи з Mercurial. Як ви побачите згодом, ці дві системи дуже схожі, тому все повинно пройти гладко.

Як і при роботі з Git, спершу ми клонуємо репозиторій:

Мабуть ви помітили, що для роботи з Mercurial-репозиторієм використовується стандартна команда git clone. Це тому, що git-remote-hg працює на доволі низькому рівні, і використовує механізм, подібний до HTTP/S протоколу в системі Git (помічники протоколу). Оскільки і Git, і Mercurial розраховані на те, що кожен клієнт має повну копію історії репозиторія, вищезгадана команда здійснює повне клонування, включно з усією історією проекту, і робить це досить швидко.

Команда git log показує два коміти, на останній з яких вказує безліч посилань. Насправді, не всі з них реально існують. Погляньмо, що знаходиться всередині директорії .git:

Git-remote-hg намагається нівелювати відмінності між Git та Mercurial, але "під капотом" він керує концептуальними перетвореннями між двома різними системами. У директорії refs/hg знаходяться посилання на об’єкти віддаленого репозиторія. Наприклад, refs/hg/origin/branches/default — це файл-посилання Git, який містить SHA-1, що починається з "ac7955c", який є комітом, на який вказує гілка master. Таким чином, директорія refs/hg — це щось схоже на refs/remotes/origin, але тут окремо зберігаються закладки та гілки.

Файл notes/hg — відправна точка для розуміння того, як git-remote-hg встановлює відповідність між хешами комітів у Git та ідентифікаторами змін у Mercurial. Погляньмо, що там:

Отже, refs/notes/hg вказує на дерево, яке в базі об’єктів Git містить перелік інших об’єктів та їхніх імен. Команда git ls-tree виводить права доступу, тип, хеш та ім’я файлу для елементів дерева. Коли ми дістанемось першого елемента дерева, ми побачимо, що всередині знаходиться блоб з іменем "ac9117f" (SHA-1 хеш коміту, на який вказує гілка master), який містить "0a04b98" (ідентифікатор останньої зміни гілки default у Mercurial).

Хорошою новиною є те, що нам не потрібно турбуватися про все це. Типовий робочий процес не буде значно відрізнятися від роботи з віддаленим репозиторієм Git.

Є ще одна річ, яку ми повинні враховувати, перш ніж продовжувати: ігноровані файли. І Mercurial, і Git використовують для цього схожий механізм, але зберігати файл .gitignore в Mercurial-репозиторії — не найкраща ідея. На щастя, в Git є можливість ігнорувати файли, що знаходяться в локальній копії репозиторія, а формат списку ігнорованих файлів в Mercurial сумісний з Git, тому вам достатньо скопіювати його:

Файл .git/info/exclude діє подібно до .gitignore, але не включається у коміт.

Нехай ми виконали певний обсяг роботи і зробили деякі коміти в гілку master, і тепер ви готові надіслати зміни до віддаленого репозиторія. Так виглядає наш репозиторій в цей момент:

Наша гілка master на два коміти попереду origin/master, але ці два коміти існують лише на нашій локальній машині. Погляньмо, раптом хтось інший зробив важливі зміни:

Оскільки ми використали --all ми бачимо посилання "notes", які використовуються всередині git-remote-hg, але ми можемо не звертати уваги на них. Все інше — саме те, що ми очікували; origin/master пішов далі на один коміт і наша історія розійшлася. На відміну від інших систем, з якими ми мали справу в цьому розділі, Mercurial вміє працювати зі злиттям, тому нам не потрібно робити жодних фокусів.

Чудово. Ми запустили наші тести і всі вони пройшли, отже, ми готові ділитися нашими напрацюваннями з рештою команди:

І це все! Якщо ви поглянете на Mercurial-репозиторій, ви переконаєтесь, що відбулось саме те, що ми й очікували:

Набір змін 2 був здійснений Mercurial’ом, а зміни 3 та 4 — за допомогою git-remote-hg шляхом надсилання комітів, зроблених з Git.

Git має лише один вид гілок: вказівник, який переміщується при комітах. У Mercurial цей вид вказівника називається "закладка", і вона поводить себе подібно до гілки в Git.

Поняття "гілка" в Mercurial більш складне. Гілка, в якій відбувається зміна, записується всередині кожної зміни, таким чином, вона завжди залишається в історії репозиторія. Ось приклад коміту, який зроблено в гілці develop:

Зверніть увагу на рядок, що починається з "branch". Git не може насправді відтворити це (і не повинен; обидва типи гілок можуть бути представлені як Git-посилання), але git-remote-hg змушений розуміти цю різницю, оскільки це важливо для Mercurial.

Створення закладок у Mercurial настільки ж просте, як створення гілок у Git. У Git ми робимо наступне:

Ось і все, що потрібно. А в Mercurial це виглядає так:

Зверніть увагу на нову мітку [featureA] у п’ятій ревізії. Це працює так само, як гілки в Git, але з одним винятком: ви не можете видаляти закладки в Git (це обмеження помічників протоколу).

Ви можете працювати і з "повноцінними" Mercurial-гілками: просто розмістіть гілку в просторі імен branches:

Ось як це виглядає в Mercurial:

Ім’я гілки "permanent" було записано разом зі змінами під номером 7.

З боку Git, робота з обома видами гілок однакова: просто переходите на гілку, робите коміт, отримуєте зміни, робите злиття і надсилаєте зміни (checkout, commit, fetch, merge, pull, і push) як завжди. Ще одна річ, про яку вам потрібно знати: Mercurial не підтримує перезапис історії, лише додавання. Ось як наш Mercurial-репозиторій виглядає після інтерактивної зміни історії та примусового надсилання змін:

Були створені зміни 8, 9 та 10 і тепер вони належать до гілки permanent, але старі зміни досі там. Це може дуже спантеличити ваших колег, які використовують Mercurial, тому краще уникати цього.

Git і Mercurial достатньо подібні для безболісної роботи один з одним. Якщо ви будете уникати змін вже опублікованої історії (що, загалом, рекомендовано), ви навіть не помітите, що працюєте в Mercurial.

It is simple to use. It is enough to clone a Bazaar repository prefixing it by bzr::. Since Git and Bazaar both do full clones to your machine, it’s possible to attach a Git clone to your local Bazaar clone, but it isn’t recommended. It’s much easier to attach your Git clone directly to the same place your Bazaar clone is attached to ‒ the central repository.

Let’s suppose that you worked with a remote repository which is at address bzr+ssh://developer@mybazaarserver:myproject. Then you must clone it in the following way:

At this point, your Git repository is created but it is not compacted for optimal disk use. That’s why you should also clean and compact your Git repository, especially if it is a big one:

Bazaar only allows you to clone branches, but a repository may contain several branches, and git-remote-bzr can clone both. For example, to clone a branch:

And to clone the whole repository:

The second command clones all the branches contained in the emacs repository; nevertheless, it is possible to point out some branches:

Some remote repositories don’t allow you to list their branches, in which case you have to manually specify them, and even though you could specify the configuration in the cloning command, you may find this easier:

Since you are working on a project managed with Bazaar, you shouldn’t create a .gitignore file because you may accidentally set it under version control and the other people working with Bazaar would be disturbed. The solution is to create the .git/info/exclude file either as a symbolic link or as a regular file. We’ll see later on how to solve this question.

Bazaar uses the same model as Git to ignore files, but also has two features which don’t have an equivalent into Git. The complete description may be found in the documentation. The two features are:

As a consequence, there are two different situations to consider:

Whatever the case is, you will have to remain vigilant against any change of .bzrignore to make sure that the .git/info/exclude file always reflects .bzrignore. Indeed, if the .bzrignore file were to change and contained one or more lines starting with "!!" or "RE:", Git not being able to interpret these lines, you’ll have to adapt your .git/info/exclude file to ignore the same files as the ones ignored with .bzrignore. Moreover, if the .git/info/exclude file was a symbolic link, you’ll have to first delete the symbolic link, copy .bzrignore to .git/info/exclude and then adapt the latter. However, be careful with its creation because with Git it is impossible to re-include a file if a parent directory of that file is excluded.

To fetch the changes of the remote, you pull changes as usually, using Git commands. Supposing that your changes are on the master branch, you merge or rebase your work on the origin/master branch:

Because Bazaar also has the concept of merge commits, there will be no problem if you push a merge commit. So you can work on a branch, merge the changes into master and push your work. Then, you create your branches, you test and commit your work as usual. You finally push your work to the Bazaar repository:

Git’s remote-helpers framework has some limitations that apply. In particular, these commands don’t work:

Since Git’s and Bazaar’s models are similar, there isn’t a lot of resistance when working across the boundary. As long as you watch out for the limitations, and are always aware that the remote repository isn’t natively Git, you’ll be fine.

Perforce забезпечує продукт, який називається Git Fusion (доступний за посиланням http://www.perforce.com/git-fusion), і синхронізує сервер Perforce з репозиторієм Git на стороні сервера.

Git-p4 — це двосторонній міст між Git та Perforce. Він працює повністю всередині вашого репозиторія Git, тому вам взагалі не потрібно мати доступ до сервера Perforce (звичайно, вам знадобляться логін і пароль). Git-p4 не такий гнучкий та функціональний, як Git Fusion, але він дозволяє здійснювати більшість з того, що вам буде необхідно, без втручання у середовище сервера.

Git-p4 робить можливим використання Git з сервером Perforce, і робить це досить добре. Однак, важливо пам’ятати, що Perforce все одно залишається джерелом даних, і ви використовуєте Git лише для локальної роботи. Будьте дуже обережні при публікації комітів Git; якщо ви маєте віддалений репозиторій, який використовують інші люди, не надсилайте жодних комітів, які ще не надіслані на сервер Perforce.

Якщо ви хочете вільно змішувати Perforce і Git як клієнти для контролю версій, і ви можете переконати адміністратора сервера встановити їх, Git Fusion зробить використання Git у якості клієнта контролю версій для сервера Perforce повноцінним.

Насправді, їх є два: git-tf та git-tfs.

Git-tfs (можна знайти за https://github.com/git-tfs/git-tfs) є .NET проектом та (на момент написання цього тексту) сумісний тільки з Windows. Для роботи з Git сховищами він використовує .NET обгортку над libgit2, бібліотеко-орієнтованою реалізацією Git, що є високопродуктивною та дозволяє багато гнучкості з нутрощами Git сховища. Libgit2 не є повною реалізацією Git, тому git-tfs використовує клієнтську командну стрічку Git для того, щоб закрити недостачу, отже, фактично, немає обмежень в тому, що ця утиліта може робити зі сховищами Git. Її підтримка особливостей TFVC є достить зрілою через те, що вона оперує з сервером через бібліотеки Visual Studio. Це значить, що вам потрібен доступ до цих бібліотек, що, в свою чергу означає, що потрібно встановити недавню версію Visual Studio (будь-яку редакцію, починаючи з версії 2010, включно з Express починаючи з 2012), або Visual Studio SDK.

Git-tf (який живе за адресою https://gittf.codeplex.com) є Java проектом і через це може працювати на будь-якому комп’ютері з Java середовищем. Він взаємодіє з Git сховищем через JGit (JVM реалізація Git), тобто, практично не має обмежень щодо функціональності Git. Проте, робота TFVC не є повною, порівняно з git-tfs – немає підтримки гілок, для прикладу.

Тому, кожен інструмент має свої сильні та слабкі сторони і є різні ситуації, коли треба надати перевагу одному над іншим. В цій книзі ми розкриємо базове використання обох.

По-перше, як і з будь-яким іншим Git проектом, склонуймо. Ось як це виглядає з git-tf:

Перший аргумент є URL до TFVC колекцій, другий має формат $/проект/гілка, а третій — це шлях до локального Git сховища, що буде створено (цей аргумент не обов’язковий). Git-tf може працювати лише з одною гілкою одночасно; якщо ви хочете зробити чекіни (checkins) до іншої гілки TFVC, то склонуйте заново з потрібної гілки.

Ось як створити повнофункціональний Git репозиторій:

Це зветься мілким (shallow) клоном, в тому значенні, що завантажено лише найостанніший ченджсет. TFVC не спроектований таким чином, що кожен клієнт має повну копію історії, тому git-tf типово отримає лише останню версію, а це є значно швидшим.

Коли ж у вас вдосталь часу, мабуть, варто клонувати всю історію проекту, за допомогою опції --deep:

Зверніть увагу на теґи з іменами типу TFS_C35189; за допомогою цієї особливості ви дізнаєтеся який Git коміт та ченджсет TFVC пов’язані між собою. Це є хорошим відображенням, оскільки ви можете за допомогою простої команди log з’ясувати які з ваших комітів також також існують в TFVC. Ці теґи не є обов’язковими (і їх насправді можна вимкнути за допомогою git config git-tf.tag false) – git-tf все одно зберігає реальні зв’язки коміт-ченджсет у файлі .git/git-tf.

Клонування в git-tfs відбувається дещо інакше. Погляньте:

Зверніть увагу на прапорець --with-branches. Git-tfs має можливість створювати відповідності між гілками TFVC та Git, а цей прапорець вказує на необхідність створювати локальні Git гілки для кожної гілки TFVC. Його використання є рекомендованим якщо ви збираєтеся робити гілки чи зливати в TFS, проте такий підхід не працюватиме з сервером старішим за TFS 2010 – до цього релізу ``гілки'' були просто теками, тому git-tfs не міг відрізнити їх від звичайних тек.

Погляньте на результуюче Git сховище:

Маємо дві локальні гілки, master та featureA, котрі відображають стартову точку клонування (Trunk в іменуванні TFVC) та дочірню гілку (featureA в TFVC). Ви можете бачити також, що `віддалене сховище'' `tfs має також кілька посилань: default та featureA, які відображають гілки TFVC. Git-tfs робить відповідність між клонованою гілкою та tfs/default, а також інші отримують свої імена.

Ще варто звернути увагу на git-tfs-id: рядки в повідомленнях коміту. Замість теґів, git-tfs використовує ці позначки для зв’язку між TFVC ченджсетами та Git комітами. З цього випливає те, що ваші Git коміти матимуть різні SHA-1 хеші до та після надсилання до TFVC.

Очевидно, далі ви б хотіли попрацювати над проектом. TFVC та TFS мають кілька особливостей що можуть ускладнити ваш робочий процес:

Для стислості, ми розглянемо лише щасливий шлях, що уникає більшість із згаданих нюансів.

Скажімо, ви виконали деяку роботу, додали кілька комітів до master, а тепер готові ділитися своїми доробками на TFVC сервері. Ось наше Git сховище:

Ми хочемо взяти відбиток коміту 4178a82 та надіслати його на TFVC сервер. Насамперед, подивимося чи хтось із колег долучався до проекту з того часу, як ми востаннє з’єднувалися:

Схоже на те, що ще хтось також працює та наші історії розійшлися. Ось де переваги Git очевидні, але ми маємо два способи продовжувати:

Вибір за вами. У цьому прикладі ми перебазовуватимемо:

Тепер ми готові до чекіну в TFVC сервер. Git-tf дає можливість вибрати: створити один ченджсет, що представлятиме всі зміни, починаючи з останньої (--shallow, що є типовою поведінкою) чи створювати по ченджсету на кожен коміт (--deep). Тут ми просто створимо один ченджсет:

Створився теґ TFS_C35348, вказуючи що TFVC має такий самий відбиток як відбиток в коміті 5a0e25e. Важливо зауважити, що не кожен Git коміт потребує точного відповідника в TFVC; коміт 6eb3eb5, наприклад, ніде не існує на сервері.

Таким є основний процес роботи. Ось ще кілька міркувань, що варто пам’ятати:

Пройдімо такий самий сценарій з git-tfs. Маємо нові коміти, зроблені в гілку master нашого Git сховища:

Тепер глянемо чи хтось додав якісь зміни, поки ми тут мудрували:

Так, виявляється, що хтось із наших колег додав TFVC ченджсет, який ми бачимо як новий коміт aea74a0, а віддалена гілка tfs/default прогресувала.

Так само як і у випадку git-tf, ми маємо дві фундаментальні опції, щоб розв’язати цю розбіжність:

В нашому випадку ми робитимемо ``глибокий'' чекін, тобто кожен Git коміт стає ченджсетом TFVC, тому виберемо варіант з перебазовуванням.

Тепер ми готові завершити наш вклад, зачекінивши код до TFVC серверу. Будемо використовувати команду rcheckin для того, щоб створювався TFVC ченджсет на кожен Git коміт від HEAD до першого віддаленого посилання tfs (команда checkin створила б просто один ченджсет, щось типу того як працює зчавлення (squashing) комітів).

Зверніть увагу на те, як після кожного успішного чекіна до TFVC сервера, git-tfs перебазовує залишкові зміни поверх щойно зробленого. Це тому, що додається поле git-tfs-id в кінці повідомлення коміту, і це змінює SHA-1 хеші. Так і було задумано, не потрібно хвилюватися з цього приводу, просто вам потрібно знати, що це відбувається; особливо, якщо ви ділитеся ідентифікаторами Git комітів з іншими.

TFS має багато особливостей для інтеграції зі своєю системою контролю версій, такі як одиниці роботи (work items), переглядальники коду, закриті (gated) чекіни тощо. Опанувати їх всіх з командного рядка може бути досить хвацькою задачею, але, на щастя, git-tfs має досить швидкий доступ і до більш візуальних інструментів чекіну:

Виглядає це якось так:

Це виглядатиме звичним для користувачів TFS, оскільки це той самий діалог, що запускається у Visual Studio.

Git-tfs також дає можливість керувати гілками TFVC з Git сховища. Для прикладу, створимо гілку:

Створення гілки в TFVC означає додавання ченджсету до гілки, що вже існує, і це відображено окремим комітом Git. Також, зверніть увагу, що git-tfs створив віддалену гілку tfs/featureBee, але HEAD досі вказує на master. Якщо вам кортить попрацювати з щойно створеною гілкою, потрібно базувати свої нові коміти на коміті 1d54865, можливо, створивши тематичну гілку з цього коміту.

Обидві Git-tf та Git-tfs є чудовими інструментами для доступу до сервера TFVC та роботи з ним. Вони дають вам локальну могутність Git, уникають постійних мандрів мережею до центрального сервера TFVC, та спрощують ваше розробницьке життя, без необхідності переходу на Git цілою командою. Якщо ви працюєте з Windows (що дуже ймовірно, коли користуєтеся TFS), то вам, мабуть, більше захочеться обрати git-tfs, через більш повний набір особливостей, а у випадку іншої платформи, ви користуватиметеся git-tf, яка є більш обмеженою. Як і з більшістю інструментів цього розділу, вам потрібно обрати одну з систем контролю версій, яка буде основною, а іншу використовувати ніби підлеглу – будь це Git чи TFVC, потрібно обрати один центр для співпраці, не обидва.