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

$git log -1

commit 775a46f630d8b46535fc9983cf3ebe6b9aa53145

Author: John Doe

Date: Sun Aug 31 10:31:44 2014 -0800

Change page title

[git-p4: depot-paths = "//depot/www/live/": change = 12144]

Что произойдёт если вы попробуете отправить коммит-слияние? Давайте попробуем. Допустим, мы имеем такую историю:

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

* 3be6fd8 (HEAD, master) Correct email address

* 1dcbf21 Merge remote-tracking branch 'p4/master'

|\

| * c4689fc (p4/master, p4/HEAD) Grammar fix

* | cbacd0a Table borders: yes please

* | b4959b6 Trademark

|/

* 775a46f Change page title

* 05f1ade Update link

* 75cd059 Update copyright

* 70eaf78 Initial import of //depot/www/live/ from the state at revision #head

История в Git разошлась с Perforce на коммит 775a46f. В Git мы имеем два дополнительные коммита, затем слияние с состоянием Perforce, затем ещё один коммит. Мы собираемся отправить эту историю в Perforce. Давайте посмотрим, что произойдёт:

$git p4 submit -n

Perforce checkout for depot path //depot/www/live/ located at /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/

Would synchronize p4 checkout in /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/

Would apply

b4959b6 Trademark

cbacd0a Table borders: yes please

3be6fd8 Correct email address

Флаг -n — это сокращение для --dry-run, который, в свою очередь, пытается вывести результат выполнения отправки, как если бы отправка на самом деле произошла. В этом случае, похоже мы создадим три ревизии в Perforce, по одной для каждой не являющейся слиянием коммита в Git. Звучит логично, давайте посмотрим что произойдёт на самом деле:

$git p4 submit

[…]

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

* dadbd89 (HEAD, p4/master, p4/HEAD, master) Correct email address

* 1b79a80 Table borders: yes please

* 0097235 Trademark

* c4689fc Grammar fix

* 775a46f Change page title

* 05f1ade Update link

* 75cd059 Update copyright

* 70eaf78 Initial import of //depot/www/live/ from the state at revision #head

История стала линейной, словно мы переместили изменения перед отправкой (что на самом деле и произошло). Это означает, что вы можете свободно создавать ветки в Git, работать в них, сливать их, не боясь, что ваша история станет несовместима с Perforce. Если вы можете переместить изменения, вы можете отправить их на Perforce сервер.

Если в вашем Perforce проекте несколько веток, не переживайте: git-p4 может организовать работу с ними, не сложнее, чем с обычными Git ветками. Предположим, ваш Perforce репозиторий имеет следующую структуру:

//depot

└── project

├── main

└── dev

Также предположим, что ветка dev настроена следующим образом:

//depot/project/main/... //depot/project/dev/...

git-p4 может автоматически распознать эту ситуацию и выполнить нужные действия:

$git p4 clone --detect-branches //depot/project@all

Importing from //depot/project@all into project

Initialized empty Git repository in /private/tmp/project/.git/

Importing revision 20 (50%)

Importing new branch project/dev

Resuming with change 20

Importing revision 22 (100%)

Updated branches: main dev

$cd project; git log --oneline --all --graph --decorate

* eae77ae (HEAD, p4/master, p4/HEAD, master) main

| * 10d55fb (p4/project/dev) dev

| * a43cfae Populate //depot/project/main/... //depot/project/dev/....

|/

* 2b83451 Project init

Обратите внимание на "@all" в пути; она говорит git-p4 клонировать не только последнюю ревизию для указанного субдерева, но все ревизии, затрагивающие указанные пути. Это ближе к оригинальной концепции клонирования в Git, но если вы работаете с большим репозиторием, это может занять некоторое время.

Флаг --detect-branches указывает git-p4 использовать настройки веток Perforce для отображения на Git ветки. Если же таких настроек на Perforce сервере нет (что вполне корректно для Perforce), вы можете можете указать их git-p4 вручную, получив аналогичный результат:

$git init project

Initialized empty Git repository in /tmp/project/.git/

$cd project

$git config git-p4.branchList main:dev

$git clone --detect-branches //depot/project@all .

Задав конфигурационный параметр git-p4.branchList равным main:dev мы указали git-p4, что "main" и "dev" — это ветки, и что вторая является потомком первой.

Если мы теперь выполним git checkout -b dev p4/project/dev и зафиксируем в ветке dev некоторые изменения, git-p4 будет достаточно смышлёным, чтобы догадаться, в какую ветку отправлять изменения при выполнении git p4 submit. К сожалению, git-p4 не позволяет использовать несколько веток в поверхностных копиях репозиториев; если у вас есть большой проект и вы хотите работать более чем в одной ветке, вам придётся выполнять git p4 clone для каждой ветки, в которую вы хотите отправлять изменения.

Для создания и интеграции веток вам нужно будет использовать Perforce клиент. git-p4 может только забирать изменения из Perforce и отправлять линейную историю обратно. Если вы произведёте слияние двух веток в Git и отправите изменения в Perforce, сохранятся лишь данные об изменении файлов, все метаданные об исходных ветках, участвующих в интеграции, будут потеряны.

git-p4 позволяет использовать Git для работы с Perforce и он достаточно хорош в этом. Тем не менее, не стоит забывать, что источником данных по-прежнему остаётся Perforce, а Git используется лишь для локальной работы. Будьте осторожны с публикацией Git коммитов: если у вас есть удалённый репозиторий, который используют другие люди, не публикуйте в нём коммиты, не отправленные на Perforce сервер.

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

Git набирает популярность среди Windows-разработчиков и если вы один из них, то велика вероятность что вы пользовались Microsoft Team Foundation Server (TFS). TFS — это комплексное решение, включающее в себя систему отслеживание ошибок, систему учёта рабочего времени, решения для поддержки Scrum методологии, инструменты для проведения инспекции кода и собственно систему контроля версий. Здесь есть небольшая путаница: TFS— это сервер, поддерживающий управление версиями как с помощью Git, так и с помощью собственной СКВ — TFVC(Team Foundation Version Control). Поддержка Git появилась в TFS относительно недавно (начиная с 2013-й версии), так что когда идёт речь об управлении версиями в более ранних версиях TFS, имеется в виду именно TFVC.

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

На самом деле, даже два проекта: git-tf и git-tfs.

git-tfs (расположившийся по адресу https://github.com/git-tfs/git-tfs) написан на .NET и (на момент написания этой книги) работает только на Windows. Он использует .NET привязки для библиотеки libgit2 для работы с Git репозиториями; это очень гибкая и эффективная библиотека, позволяющая выполнять множество низкоуровневых операций с Git репозиторием. Но libgit2 не полностью покрывает функциональность Git, так что в некоторых случаях git-tfs вызывает консольный клиент Git, что делает его возможности по работе с репозиториями практически безграничными. Поддержка TFVC также впечатляет своей полнотой, ведь git-tfs использует "родные" .NET-сборки Visual Studio для работы с сервером. И это не означает, что вам нужен будет доступ к этим сборкам! Достаточно лишь установить свежую версию Visual Studio (любую, начиная с 2010-й, включая Express, начиная с 2012-й) или комплект средств разработки для Visual Studio (Visual Studio SDK).