Скотт Чакон - Pro Git

* 8f77431 (tag: TFS_C35178) FIRST

* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \

Team Project Creation Wizard

Теперь всё готово к отправке данных на TFVC сервер. git-tf предоставляет вам выбор: собрать все изменения воедино и сделать из них один набор изменений (опция --shallow, по умолчанию включённая), или создать отдельный набор изменений для каждого коммита в Git (опция --deep). В этом примере мы создадим один набор изменений:

$git tf checkin -m 'Updating readme and code'

Username: domain\user

Password:

Connecting to TFS...

Checking in to $/myproject: 100%, done.

Checked commit 5a0e25e in as changeset 35348

$git log --oneline --graph --decorate --all

* 5a0e25e (HEAD, tag: TFS_C35348, origin_tfs/tfs, master) update code

* 6eb3eb5 update readme

* 8ef06a8 (tag: TFS_C35320) just some text

* d44b17a (tag: TFS_C35190) Goodbye

* 126aa7b (tag: TFS_C35189)

* 8f77431 (tag: TFS_C35178) FIRST

* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \

Team Project Creation Wizard

Появилась новая метка TFS_C35348, указывающая на то, что TFVC сохранил слепок состояния 5a0e25e под этим идентификатором. Обращаем ваше внимание, что не каждый коммит в Git имеет аналог в TFVC; например 6eb3eb5 не представлен на сервере.

Такой вот рабочий процесс. И ещё несколько важных моментов:

● Нет веток. git-tf умеет создавать Git-репозитории, соответствующие единственной ветке в TFVC.

● Делитесь наработками либо через TFVC-сервер, либо через Git-сервер, не используйте их одновременно. Разные git-tf клоны одного и того же TFVC-репозитория могут иметь различные SHA-1 хеши, что сулит нескончаемую головную боль.

● Если ваш рабочий процесс выстроен таким образом, что вы делитесь наработками через Git и лишь периодически синхронизируетесь с TFVC, не используйте более одного Git репозитория.

Давайте пробежимся по тому же сценарию в git-tfs. Вот новые коммиты в ветке master в нашем Git репозитории:

PS> git log --oneline --graph --all --decorate

* c3bd3ae (HEAD, master) update code

* d85e5a2 update readme

| * 44cd729 (tfs/featureA, featureA) Goodbye

| * d202b53 Branched from $/tfvc-test/Trunk

|/

* c403405 (tfs/ default) Hello

* b75da1a New project

Проверим, что успели сделать другие:

PS> git tfs fetch

C19 = aea74a0313de0a391940c999e51c5c15c381d91d

PS> git log --all --oneline --graph --decorate

* aea74a0 (tfs/ default) update documentation

| * c3bd3ae (HEAD, master) update code

| * d85e5a2 update readme

|/

| * 44cd729 (tfs/featureA, featureA) Goodbye

| * d202b53 Branched from $/tfvc-test/Trunk

|/

* c403405 Hello

* b75da1a New project

Пока мы работали, в TFVC появились свежие изменения, соответствующие коммиту aea74a0, и удалённая ветка tfs/default передвинулась.

Как и в случае с git-tf, у нас есть два пути решения этой проблемы:

1. Переместить изменения и сделать историю линейной.

2. Произвести слияние, сохранив историческую достоверность.

Мы хотим, чтобы каждому коммиту в Git соответствовал набор изменений в TFVC, так что мы будем перемещать изменения и делать историю линейной.

PS> git rebase tfs/ default

First, rewinding head to replay your work on top of it...

Applying: update readme

Applying: update code

PS> git log --all --oneline --graph --decorate

* 10a75ac (HEAD, master) update code

* 5cec4ab update readme

* aea74a0 (tfs/ default) update documentation

| * 44cd729 (tfs/featureA, featureA) Goodbye

| * d202b53 Branched from $/tfvc-test/Trunk

|/

* c403405 Hello

* b75da1a New project

Теперь мы готовы отправить наши наработки на TFVC сервер. Для этого мы используем команду rcheckin, которая сопоставляет каждому коммиту в Git новый набор изменений в TFVC (команда checkin создала бы только один набор изменений, примерно как опция squash при интерактивном перемещении изменений).

PS> git tfs rcheckin

Working with tfs remote: default

Fetching changes from TFS to minimize possibility of late conflict...

Starting checkin of 5cec4ab4 'update readme'

add README.md

C20 = 71a5ddce274c19f8fdc322b4f165d93d89121017

Done with 5cec4ab4b213c354341f66c80cd650ab98dcf1ed, rebasing tail onto new TFS-commit...

Rebase done successfully.

Starting checkin of b1bf0f99 'update code'

edit .git\tfs\ default\workspace\ConsoleApplication1/ConsoleApplication1/Program.cs

C21 = ff04e7c35dfbe6a8f94e782bf5e0031cee8d103b

Done with b1bf0f9977b2d48bad611ed4a03d3738df05ea5d, rebasing tail onto new TFS-commit...

Rebase done successfully.

No more to rcheckin.

PS> git log --all --oneline --graph --decorate

* ff04e7c (HEAD, tfs/ default, master) update code

* 71a5ddc update readme

* aea74a0 update documentation

| * 44cd729 (tfs/featureA, featureA) Goodbye

| * d202b53 Branched from $/tfvc-test/Trunk

|/

* c403405 Hello

* b75da1a New project

Обратите внимание, как после каждой удачной ревизии на TFVC сервере git-tfs перемещает оставшиеся к отправке изменения на вновь созданные коммиты. Это необходимо, потому что git-tfs добавляет строку git-tfs-id к сообщениям коммитов, меняя, таким образом, их SHA-1 хеши. Это запланированное поведение и вам не о чем беспокоиться, просто помните об этом, особенно если вы публикуете эти коммиты где-либо ещё.

У TFS ещё много козырей в рукаве, типа курируемых наборов изменений, привязки ревизий к задачам, инспекция кода и прочее. Возможно, кому-то покажется сложной работа с этими возможностями через командную строку. К счастью, в git-tfs вы можете использовать графическую утилиту: