¿Cómo puedo configurar Git para confirmaciones locales mientras uso P4 para confirmaciones remotas?

Donde yo trabajo utiliza un entorno de Perforce, pero no podemos registrarnos hasta que nuestras características estén completas y lists para ser probadas. Necesito poder realizar confirmaciones locales porque a veces he tenido más de 50 files desprotegidos durante una semana sin ninguna versión de mis cambios.

Git se adapta a mi propósito, pero no estoy seguro de cómo configurarlo para que se integre mejor con el rest de mi entorno.

Mis objectives son:

  • Cuando trabajo en una function me gustaría poder ignorar por completo Perforce y editar y comprometer tanto como quiera (en Git).
  • Antes de enviar una característica, necesito poder entrar en P4V o P4Win para diferenciar los files y asegurarme de que todo esté actualizado, y después de probar me gustaría que todos mis cambios estén en una única confirmación.

Parece que crear un repository de git en el directory raíz de mi espacio de trabajo local funcionaría, pero tengo algunos problemas …

  1. Hay una gran cantidad de files en este repository y al less con el commit inicial git se está rastreando.
  2. Necesito poder actualizar fácilmente el repository de git cuando obtengo el último de Perforce
  3. No quiero tener que ocuparme de revisar cada file en Perforce antes de editarlo, ni quiero tener que hacer una Force Sync en Perforce porque son files editables que no están desprotegidos.

¿Alguien puede darme algunos consejos sobre esto? He estado buscando en los submodules en git como una forma de networkingucir potencialmente el tamaño del repository git ya que hay muchas partes del repository forzado en las que no necesito versiones.

Deberías ir con git-p4 . Esta respuesta también podría ser útil.

Actualmente estoy usando exactamente este flujo de trabajo y es bastante bueno

Por razones corporativas, no puedo usar los commands de git-p4, pero tengo un git repo viviendo dentro del directory del espacio de trabajo de mi cliente. Nuestra configuration solo tiene código de configuration registrado en el control de fuente, y el rest de la configuration del desarrollador está almacenada en un ZIP. Por lo tanto, nunca conciliar en la raíz del espacio de trabajo de todos modos, que tiene la ventaja adicional de no tener que ignorar explícitamente .git .

Abordar sus puntos:

  1. Se puede esperar que la confirmación inicial sea … bueno, no la más rápida. No está clonando un repository existente, está construyendo uno desde cero.

  2. De vez en cuando voy a save + comprometer lo que estoy trabajando,

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

    y luego continuar hackear. Las fusiones tienden a ser mucho más fluidas en Git que en Perforce, por lo que normalmente no tendrás que desviar la atención debido a los conflictos. @ p4mataway me dijo que están trabajando para fusionarse mejor, sin embargo, así será limpio de ver.

  3. Active la opción de espacio de trabajo 'allwrite' (no guarde los files sin editar de solo lectura) y cuando esté listo para verificar algo, fusionaré esa twig en master y luego reconciliaré en P4V. Lo haría desde la command-line también, razones corporativas otra vez. Larga historia.

Git me ha sido tremendamente útil cuando se trata de características que implican múltiples cambios en el mismo file, como suele ocurrir con los cambios pendientes, típicamente cambios en el esquema de la database que requieren que la database de nuestra aplicación se reinicie y no queremos hacer eso en los serveres de testing en este momento porque el QA se encuentra en el medio de los escenarios. Mientras más time permanezca una list de cambios, es más probable que un trabajo no relacionado toque uno de los mismos files, y poder realizar una bifurcación local evita que los cambios se acumulen. Esa característica por sí sola es suficiente para que toda esta configuration valga la pena por completo.

Descargo de responsabilidad: no tengo la intención de mantener este repository de Git para siempre. Una vez que se resuelvan algunas de las razones corporativas con una próxima actualización del server, podré usar algunas características muy shinys de Perforce que nuestro entorno actual no admite.

Hago lo mismo en el trabajo con StarTeam y git. No estoy familiarizado con la syntax obligatoria, pero los conceptos deben coincidir.

En primer lugar, la confirmación inicial de git es siempre lenta. Después de eso, podría tomar de 5 a 10 segundos escanear los files modificados para la puesta en escena, pero la confirmación debería ocurrir casi instantáneamente la mayor parte del time. Por context, nuestra base de código tiene aproximadamente 50,000 files versionados.

Mantengo el master sincronizado con StarTeam, pero no hago ningún trabajo de desarrollo directamente en él. Hago un git checkout master , luego hago una actualización de StarTeam, luego un git add y commit.

Luego, para mi trabajo, hago una nueva sucursal, hago todo mi trabajo allí, hago otra actualización de StarTeam en master y vuelvo a fusionar mi twig de características en master antes de comprometerme con StarTeam. Por lo tanto, los check in y outs de StarTeam se realizan todos en master , y el desarrollo siempre se realiza en otras sucursales, lo que mantiene limpias las actualizaciones de StarTeam.

Este enfoque mixto tiene otros beneficios agradables, como la posibilidad de suspender el trabajo parcial durante un time para revisiones de códigos, problemas de campo o lo que sea. Actualmente tengo 5 twigs de git en varios estados de uso. También es muy bueno para poner código de debugging temporal.

Aquí hay una solución cruda. Después de sincronizar desde p4 , p4 un git init en ese directory, agregue todos los files y complételos. Haz tu trabajo ignorando por completo a git y luego agrégalo nuevamente a la p4 .

Esto y algunas cosas relacionadas fueron una discusión en esta pregunta .

Como está utilizando P4V de todos modos, le recomendaría que al less pruebe la opción de soporte sin connection relativamente nueva. Te permite la mayoría de lo que estás pidiendo (excepto el uso de Git).