Русский ▾ Topics ▾ Latest version ▾ git-p4 last updated in 2.52.0

НАЗВАНИЕ

git-p4 — Импорт из репозиториев Perforce и отправка в них

ОБЗОР

git p4 clone [<параметры-синхронизации>] [<параметры-клонирования>] <путь-к-p4-депо>…​
git p4 sync [<параметры-синхронизации>] [<путь-к-p4-депо>…​]
git p4 rebase
git p4 submit [<параметры-отправки>] [<имя-главной-ветки>]

ОПИСАНИЕ

Эта команда предоставляет способ взаимодействия с репозиториями p4 с использованием Git.

Создаёт новый репозиторий Git из существующего репозитория p4 с помощью git p4 clone, указывая ему один или несколько путей в депо p4. Включает новые коммиты из изменений p4 с помощью git p4 sync. Команда sync также используется для включения новых веток из других путей в депо p4. Отправляет изменения Git обратно в p4 с помощью git p4 submit. Команда git p4 rebase выполняет синхронизацию и перемещает текущую ветку поверх обновлённой внешней ветки p4.

ПРИМЕРЫ

  • Клонировать репозиторий:

    $ git p4 clone //depot/путь/проект
  • Выполнить некоторую работу во вновь созданном репозитории Git:

    $ cd проект
    $ vi foo.h
    $ git commit -a -m "отредактирован foo.h"
  • Обновить репозиторий Git последними изменениями из p4, перемещая вашу работу поверх:

    $ git p4 rebase
  • Отправить ваши коммиты обратно в p4:

    $ git p4 submit

КОМАНДЫ

Клон

Как правило, git p4 clone используется для создания нового каталога Git из существующего репозитория p4:

$ git p4 clone //depot/путь/проект

Этот:

  1. Создаёт пустой репозиторий Git в подкаталоге с именем проект.

  2. Импортирует полное содержимое головной редакции из указанного пути в депо p4 в один коммит в ветке Git refs/remotes/p4/master.

  3. Создаёт локальную ветку master из этого внешнего репозитория и переключает её.

Чтобы воспроизвести всю историю p4 в Git, используйте модификатор @all в пути депо:

$ git p4 clone //depot/путь/проект@all

Синхронизация

По мере продолжения разработки в репозитории p4 эти изменения могут быть включены в репозиторий Git с помощью:

$ git p4 sync

Эта команда находит новые изменения в p4 и импортирует их как коммиты Git.

Репозитории P4 также могут быть добавлены в существующий репозиторий Git с помощью git p4 sync:

$ mkdir repo-git
$ cd repo-git
$ git init
$ git p4 sync //путь/в/вашем/perforce/депо

Это импортирует указанное депо в refs/remotes/p4/master в существующий репозиторий Git. Параметр --branch можно использовать для указания другой ветки для содержимого p4.

Если репозиторий Git включает ветки refs/remotes/origin/p4, они будут получены и проверены в первую очередь во время git p4 sync. Поскольку импорт непосредственно из p4 значительно медленнее, чем получение изменений из внешнего репозитория Git, это может быть полезно в среде с несколькими разработчиками.

Если есть несколько веток, выполнение git p4 sync автоматически использует алгоритм "ОБНАРУЖЕНИЕ ВЕТОК", чтобы попытаться распределить новые изменения по правильным веткам. Это можно переопределить с помощью параметра --branch, чтобы указать только одну ветку для обновления.

Перебазировать

Распространённый рабочий шаблон — получить последние изменения из депо p4 и слить их с локальными незафиксированными изменениями. Часто репозиторий p4 является конечным местом для всего кода, поэтому рабочий процесс с перемещением имеет смысл. Эта команда выполняет git p4 sync, а затем git rebase, чтобы переместить локальные коммиты поверх обновлённых изменений p4.

$ git p4 rebase

Отправка

Отправка изменений из репозитория Git обратно в репозиторий p4 требует отдельного рабочего пространства клиента p4. Это должно быть указано с помощью переменной среды P4CLIENT или переменной конфигурации Git git-p4.client. Клиент p4 должен существовать, но корень клиента будет создан и заполнен, если он ещё не существует.

Чтобы отправить все изменения, которые находятся в текущей ветке Git, но не в ветке p4/master, используйте:

$ git p4 submit

Чтобы указать ветку, отличную от текущей, используйте:

$ git p4 submit тематическая-ветка

Чтобы указать один коммит или диапазон коммитов, используйте:

$ git p4 submit --commit <sha1>
$ git p4 submit --commit <sha1..sha1>

Вышестоящая ссылка обычно refs/remotes/p4/master, но может быть переопределена с помощью параметра командной строки --origin=.

Изменения p4 будут созданы от имени пользователя, вызывающего git p4 submit. Параметр --preserve-user приведёт к изменению владельца в соответствии с автором коммита Git. Этот параметр требует прав администратора в p4, которые могут быть предоставлены с помощью p4 protect.

Чтобы отложить изменения вместо отправки, используйте --shelve и --update-shelve:

$ git p4 submit --shelve
$ git p4 submit --update-shelve 1234 --update-shelve 2345

Забрать из ящика

Снятие с полки возьмёт отложенный список изменений P4 и создаст эквивалентный коммит git в ветке refs/remotes/p4-unshelved/<список-изменений>.

Коммит git создаётся относительно текущей редакции origin (по умолчанию HEAD). Родительский коммит создаётся на основе origin, а затем на его основе создаётся коммит unshelve.

Редакцию origin можно изменить с помощью параметра "--origin".

Если целевая ветка в refs/remotes/p4-unshelved уже существует, старая будет переименована.

$ git p4 sync
$ git p4 unshelve 12345
$ git show p4-unshelved/12345
<отправить больше изменений через p4 в те же файлы>
$ git p4 unshelve 12345
<отказывается снимать с полки, пока git снова не синхронизируется с p4>

ПАРАМЕТРЫ

Общие параметры

Все команды, кроме clone, принимают эти параметры.

--git-dir <каталог>

Установить переменную окружения GIT_DIR. См. git[1].

-v
--verbose

Предоставлять больше информации о ходе выполнения.

Параметры синхронизации

Эти параметры могут использоваться как в начальном clone, так и в последующих операциях sync.

--branch <ссылка>

Импортировать изменения в <ссылка> вместо refs/remotes/p4/master. Если <ссылка> начинается с refs/, она используется как есть. В противном случае, если она не начинается с p4/, добавляется этот префикс.

По умолчанию <ссылка>, не начинающаяся с refs/, рассматривается как имя отслеживаемой внешней ветки (в refs/remotes/). Это поведение можно изменить с помощью параметра --import-local.

Значение по умолчанию для <ссылка> — "master".

Этот пример импортирует новый внешний репозиторий "p4/proj2" в существующий репозиторий Git:

    $ git init
    $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
--detect-branches

Использовать алгоритм обнаружения веток для поиска новых путей в p4. Он описан ниже в разделе "ОБНАРУЖЕНИЕ ВЕТОК".

--changesfile <файл>

Импортировать точно номера изменений p4, перечисленные в файле, по одному на строку. Обычно git p4 проверяет текущее состояние репозитория p4 и обнаруживает изменения, которые следует импортировать.

--silent

Не выводить никакой информации о ходе выполнения.

--detect-labels

Запрашивать в p4 метки, связанные с путями депо, и добавлять их как метки в Git. Ограниченная полезность, поскольку импортирует только метки, связанные с новыми списками изменений. Устарело.

--import-labels

Импортировать метки из p4 в Git.

--import-local

По умолчанию ветки p4 хранятся в refs/remotes/p4/, где они будут рассматриваться как отслеживаемые внешние ветки командами git-branch[1] и другими. Этот параметр вместо этого помещает ветки p4 в refs/heads/p4/. Обратите внимание, что будущие операции синхронизации также должны указывать --import-local, чтобы они могли найти ветки p4 в refs/heads.

--max-changes <число>

Импортировать не более число изменений, а не весь диапазон изменений, включённый в данный спецификатор редакции. Типичное использование: указать @all в качестве спецификатора редакции, но затем использовать --max-changes 1000, чтобы импортировать только последние 1000 редакций вместо всей истории редакций.

--changes-block-size <n>

Внутренний размер блока, используемый при преобразовании спецификатора редакции, такого как @all, в список конкретных номеров изменений. Вместо использования одного вызова p4 changes для поиска полного списка изменений для преобразования выполняется последовательность вызовов p4 changes -m, каждый из которых запрашивает один блок изменений указанного размера. Размер блока по умолчанию — 500, что обычно должно быть подходящим.

--keep-path

Сопоставление имён файлов из пути депо p4 в Git по умолчанию включает удаление всего пути депо. С этим параметром полный путь депо p4 сохраняется в Git. Например, путь //depot/main/foo/bar.c при импорте из //depot/main/ становится foo/bar.c. С --keep-path путь Git вместо этого будет depot/main/foo/bar.c.

--use-client-spec

Использовать спецификацию клиента для поиска списка интересующих файлов в p4. См. раздел «СПЕЦИФИКАЦИЯ КЛИЕНТА» ниже.

-/ <путь>

Исключать выбранные пути депо при клонировании или синхронизации.

Параметры клонирования

Эти параметры могут использоваться в начальном clone вместе с описанными выше параметрами sync.

--destination <каталог>

Где создать репозиторий Git. Если не указано, для создания нового каталога используется последний компонент пути депо p4.

--bare

Выполнить голое клонирование. См. git-clone[1].

Параметры отправки

Эти параметры можно использовать для изменения поведения git p4 submit.

--origin <коммит>

Вышестоящее местоположение, из которого идентифицируются коммиты для отправки в p4. По умолчанию это самый последний коммит p4, достижимый из HEAD.

-M

Обнаруживать переименования. См. git-diff[1]. Переименования будут представлены в p4 с использованием явных операций move. Нет соответствующего параметра для обнаружения копий, но есть переменные как для перемещений, так и для копий.

--preserve-user

Изменять автора изменений p4 перед отправкой в p4. Этот параметр требует прав администратора p4.

--export-labels

Экспортировать метки из Git как метки p4. Метки, найденные в Git, применяются к рабочему каталогу perforce.

-n
--dry-run

Показать только то, какие коммиты были бы отправлены в p4; не изменять состояние в Git или p4.