Итак, что лучше: использовать git-p4 или просто вставить каталог .git в рабочий каталог и, если выполняются, игнорировать его?

Question

Я знаю, что это пришло вверх раньше, но было немного на пути повседневного личного опыта в сообщениях, которые я видел. Всего пара ответов. Я хотел бы услышать от людей, которые используют git-p4 или использовали git «под прикрытием» в репозитории Perforce, или, предпочтительно, оба.
И для тех людей, которые просто используют git под другим контролем версий, я хотел бы услышать, как вы справляетесь с уведомлением основного контроля версий об изменениях. В частности, с помощью git / Perforce, когда вы закончите и будете готовы зафиксировать изменения на сервере Perforce, как вы справляетесь с сообщением Perce, какие изменения были?
Я изучал пост-коммитные хиты с git, но я бы хотел услышать любые другие идеи.

Answer 1

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

---

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

Answer 2

Я использую git с TFS и выбрал вариант 2: вставьте каталог .git, и TFS его проигнорирует. Я делаю это по той же причине, что и @Noufal, у нас есть культура «один большой коммит» против десятков крошечных коммитов, которые я делаю в Git. Поскольку я выполняю TFS только один или два раза в день, для меня не стоит возиться с перехватами после коммита, перебазированием или чем-то еще.

Answer 3

Способ, которым я это делаю, - это иметь основную ветку и ветви функций в git, а затем использовать git diff --name-only master в ветви функций, чтобы выяснить, какие файлы я изменил для конкретной функции. Затем я проверяю эти файлы в списке изменений Perforce и отправляю его.

... ну, более или менее ... :) На практике мы используем Code Collaborator для проверки кода, поэтому я проверяю файлы между началом работы над функцией и передачей файлов для проверки кода ( не имеет большого значения, когда). Затем я проверяю перед проверкой кода, что у меня есть все файлы, которые у меня должны быть, используя приведенную выше команду git. (На самом деле, потому что я параноик, теперь я делаю git clean -xdf в своем исходном каталоге и выполняю "Примирить автономную работу" Perforce, чтобы дважды проверить, что я собираюсь отправить. Затем я делаю полную перестройку всего В конце концов, ломать сборку - это стыдно. После того, как все проверки завершены, я просто отправляю список изменений как обычно.

Это немного бред, правда, но теперь все не так плохо, как я к этому привык - и это намного лучше, чем просто использовать Perforce с массивными коммитами и эффективно работать без какого-либо контроля версий для дней за раз:)

Answer 4

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

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