Как настроить Git для локальных коммитов при использовании P4 для удаленных коммитов?

Question

В тех случаях, когда я работаю, используется среда Perforce, но нам не разрешено регистрироваться, пока наши функции не будут завершены и не будут готовы к тестированию. Мне нужно иметь возможность выполнять локальные коммиты, потому что время от времени я получал более 50 файлов, извлеченных за неделю, без каких-либо версий моих изменений.

Git соответствует моей цели, но я не уверен, как настроить его так, чтобы он наилучшим образом интегрировался с остальной частью моего окружения.

Мои цели:

• При работе с функцией я бы хотел бы иметь возможность полностью игнорировать Выполнять, редактировать и фиксировать как можно больше как мне угодно (в Git).
• Перед отправкой функции мне нужно чтобы иметь возможность войти в P4V или P4Win, чтобы проверить файлы и убедиться, все актуально, а после тестирование я хотел бы все мои изменения быть в одном коммите.

Кажется, что создание репозитория git в корневом каталоге моего локального рабочего пространства будет работать, но у меня есть некоторые проблемы ...

1. В этом хранилище огромное количество файлов, и по крайней мере при начальной фиксации сканируется git.
2. Мне нужно иметь возможность легко обновлять git-репозиторий, когда я "получаю последнюю версию" от Perforce
3. Я не хочу иметь дело с проверкой каждого файла в Perforce перед тем, как редактировать его, а также не хочу выполнять принудительную синхронизацию в Perforce, потому что это записываемые файлы, которые не извлекаются.

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

Answer 1

В настоящее время я использую именно этот рабочий процесс, и он довольно хорош

По корпоративным причинам я не могу использовать команды git-p4, но у меня есть git-репо, живущий в моем каталоге рабочего пространства клиента. В нашей настройке есть только код конфигурации, зарегистрированный в системе контроля версий, а остальные настройки dev хранятся в ZIP-архиве. Таким образом, в любом случае я никогда не примиряюсь с корнем рабочей области, который имеет дополнительный бонус - нет необходимости явно игнорировать .git.

Адресация ваших очков:

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

2. Иногда я сохраняю + фиксирую то, над чем работаю,

   git checkout master && p4 sync && git add --all . && git commit -mupdate && git checkout feature-branch
   

   а затем продолжайте взламывать. Слияния в Git, как правило, на намного более плавные, чем в Perforce, поэтому обычно вам не придется разбивать фокус из-за конфликтов. @ p4mataway сказал мне, что они работают над улучшением слияния, так что это будет здорово видеть.

3. Я включил опцию «allwrite» для рабочего пространства (не оставляйте неотредактированные файлы доступными только для чтения), и когда я буду готов что-то проверить, я объединю эту ветку до master, а затем Примирить в P4V. Я бы сделал это и из командной строки, но опять же по корпоративным причинам. Длинная история.

Git был чрезвычайно полезен для меня при работе с функциями, которые включают в себя несколько изменений в одном и том же файле, как это обычно происходит с давно ожидаемыми изменениями - обычно изменения схемы базы данных, которые требуют сброса базы данных нашего приложения, и мы не хочу сделать это на тестовых серверах прямо сейчас, потому что QA находятся в середине сценариев. Чем дольше хранится список изменений, тем больше вероятность, что какая-то несвязанная работа коснется одного и того же файла, а возможность локального ветвления предотвращает слипание изменений. Одной этой функции достаточно, чтобы сделать всю эту установку полностью стоящей.

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

Answer 2

Вы должны пойти с git-p4 . Этот ответ также может быть полезен.

Answer 3

Поскольку вы все равно используете P4V, я бы рекомендовал вам по крайней мере попробовать относительно новую опцию offline support . Он позволяет вам получить большую часть того, что вы просите (за исключением использования Git).

Answer 4

Вот грубое решение. После синхронизации с p4 выполните git init в этом каталоге, добавьте все файлы и зафиксируйте их. Выполняйте свою работу, полностью игнорируя git, а затем добавляйте и фиксируйте их обратно в p4.

Это и некоторые связанные с этим вещи обсуждались в этом вопросе .

Answer 5

Я делаю то же самое при работе со StarTeam и git.Я не знаком с синтаксисом Perforce, но концепции должны совпадать.

Прежде всего, начальный коммит git всегда медленный.После этого может потребоваться 5-10 секунд для сканирования измененных файлов для подготовки, но в большинстве случаев фиксация происходит почти мгновенно.Для контекста, наша база кода содержит около 50 000 файлов с версиями.

Я синхронизирую master со StarTeam, но не занимаюсь разработкой непосредственно в нем.Я делаю git checkout master, затем делаю обновление StarTeam, затем добавляю и комментирую git.

Затем для своей работы я делаю новую ветку, делаю всю свою работу там, делаю еще одно обновление StarTeam в master и объединить мою ветку с функциями обратно в master перед фиксацией в StarTeam.Таким образом, все входы и выходы StarTeam выполняются в master, а разработка всегда выполняется в других ветвях, что обеспечивает чистоту обновлений StarTeam.

Этот смешанный подход имеет ряд других приятных преимуществ, таких как возможностьна некоторое время отложите частичную работу для проверки кода, проблем с полями или чего-то еще.В настоящее время у меня есть 5 веток git в различных состояниях использования.Это также очень удобно для ввода временного кода отладки.