*** ВНИМАНИЕ: Блог переехал на другой адрес - demin.ws ***

четверг, 28 апреля 2011 г.

p4-git - работа в Perforce через git

Наша основная система контроля версий - Perforce. Если уж говорить о централизованных системах контроля версий, то с моей точки зрения, Perforce - это лучшая система из тех, с которыми мне доводилось работать. Например:

  • CVS - все понятно, система не для автоматизации разработки, где все меняется каждую минуту, а для "публикации истории изменений"
  • SVN - все более менее ничего, когда в разработке есть выделенный trunk, иначе после нескольких массивных слияний веток в разных направлениях хочется застрелиться
  • RTC (Rational Team Concert) - монструозная система, удобная когда все и везде написано только на Java, и неудобный клиент в командной строке
  • ClearCase - кроме шуток, пользователям надо выдавать травы и водки, чтобы понять, как это система работает

На фоне всего этого Perforce - это реальный рай. Регулярно делаю слияния между ветками команд разработчиков, интеграцией и релизами - удобно. Также смотря с позиции ежедневных нужд разработчика - также все удобно. Только одна вещь нас немного мучала - это невозможность перебрасывать changeset'ы между физическими машинами перед commit'ом. У нас в разработке шесть основных платформ, включая Windows, поэтому каждый commit приходится проверять на всех платформах. Моя утилита p4patch решала проблему более менее, но в последних версиях появилась волшебная команда p4 shelve, которая решает эту проблему на корню.

Но что ни говори, для локальной работы, когда утопаешь в экспериментах, тестовых данных, временных копиях и т.д. - наличие распределенной системы типа git, hg, bazaar или fossil, когда можно плодить ветки по каждому чиху, сливать, удалять и т.д., реально упрощает жизнь.

Как рекоммендуют сами Perforce'овцы, можно в некотором роде срастить оба подхода, например, через git.

p4-git - скрипт, которым локальные файлы, находящиеся под контролем Perforce, дополнительно можно взять под git.

Я все настроил, как сказано. Теперь у меня в git есть ветка master, являющаяся зеркалом из репозитория Perforce, и пяток-десяток локальных веток, из которых я сливаю в master. Изменения, которые я внес через git, автоматически заливаются в Perforce командой "git p4 submit". Комадной же "git p4 rebase" можно синхронизировать ветку master с ее оригиналом в Perforce.

Кстати, я уже потерял счет тем разам, когда в hg или fossil'e я влеплял ошибку в команде комита - либо просто опечатка в сообщении, что еще можно пережить, или при повторении команд из буфера командой строки вместо diff залепишь старый комит и все. Потом приходится либо как-то хитро merge'ить, либо просто откатывать изменения, делая новый комит. А в git можно просто сказать "git commit --amend" для исправления опечатки в только что сделанном комите, или "git reset HEAD^1" для удаления последнего комита вообще. А меняя 1 на 2, 3 и т.д., можно удалить сколько угодно комитов назад.

А самое важное, что даже неверная команда "git reset HEAD^n", которая якобы удаляет n последних комитов - это не конец света. И ее можно откатить через "git reset <commit_id>", где <commit_id> - это идентификатор удаленного комита. При всех тех возможностях по работе с репозиторием, которые дает git, и которые принято считать "опасными", очень мало команд, которые реально имеют необратимые последствия. Пока вы не сделали сборку мусора командой "git repack" объекты физически не удаляются, а только меняются указатели на них, а значит практически всегда можно вернуть назад, когда напортачил.

1 комментарий:

  1. А в hg есть reset? Порой то файлы забываю добавить, то ещё хуже ...

    ОтветитьУдалить