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

Question

Donde trabajo utiliza un entorno de Perforce, pero no podemos registrarnos hasta que nuestras características estén completas y listas para ser probadas. Necesito poder realizar confirmaciones locales porque a veces he tenido más de 50 archivos 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 resto de mi entorno.

Mis objetivos son:

• Cuando se trabaja en una función que me gustaría ser capaz de ignorar por completo Perforce y editar y comprometerse tanto lo que quiera (en Git).
• Antes de presentar una característica, necesito ser capaz de entrar en P4V o P4Win a diff los archivos y asegúrese de todo está al día, y después de las pruebas me gustaría que todos mis cambios estar en una compromiso único.

Parece que la creación de un repositorio git en el directorio raíz de mi espacio de trabajo local iba a funcionar, pero tengo algunos problemas ...

1. Hay una enorme cantidad de archivos en este repositorio y al al menos con la confirmación inicial, git está rastreando.
2. Necesito ser capaz de actualizar fácilmente el repositorio de git cuando "obtengo lo último" de Perforce
3. No quiero tener que ocuparme de revisar cada archivo en Perforce antes de editarlo, ni quiero tener que hacer una Force Sync en Perforce porque son archivos editables que no están desprotegidos.

¿Alguien me puede dar algunos consejos al respecto? He estado buscando en los submódulos en git como una forma de reducir potencialmente el tamaño del repositorio git ya que hay muchas partes del repositorio forzado en las que no necesito versiones.

Answer 1

Hago lo mismo en el trabajo con StarTeam y git. No estoy familiarizado con la sintaxis 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 archivos modificados para la puesta en escena, pero la confirmación debería ocurrir casi instantáneamente la mayor parte del tiempo. Por contexto, nuestra base de código tiene aproximadamente 50,000 archivos versionados.

Guardo 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 rama de características en master antes de comprometerme con StarTeam. Por lo tanto, las comprobaciones y salidas de StarTeam se realizan en el master, y el desarrollo siempre se realiza en otras sucursales, lo que mantiene limpias las actualizaciones de StarTeam.

Este enfoque mixto tiene algunos otros beneficios agradables, como poder poner el trabajo parcial en espera por un tiempo para revisiones de código, problemas de campo, o lo que sea. Actualmente tengo 5 ramas de git en varios estados de uso. También es muy bueno para poner código de depuración temporal.

Answer 2

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

Esto y algunas cosas relacionadas se discutieron en this question.

Answer 3

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

Answer 4

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

Answer 5

actualmente estoy usando exactamente este flujo de trabajo y es bastante grande

Por razones corporativas que no puedo utilizar los comandos git-p4, pero tengo un acuerdo de recompra de estar git dentro de mi directorio de espacio de trabajo cliente. Nuestra configuración solo tiene código de configuración registrado en el control de fuente, y el resto de la configuración 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.

Direccionamiento de sus puntos:

1. El inicial cometen se puede esperar que sea ... bueno, no el más rápido. No está clonando un repositorio existente, está construyendo uno desde cero.

2. De vez en cuando voy a guardar + cometer lo que estoy trabajando,

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

   y luego continuar a cortar. Las fusiones tienden a ser mucho más suaves en Git que en Perforce, por lo que normalmente no tendrá que interrumpir el enfoque debido a conflictos. @p4mataway me dijeron que están trabajando para fusionarse mejor, sin embargo, así será fácil de ver.

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

Git ha sido tremendamente útil para mí cuando se trata de características que involucran a múltiples cambios en el mismo archivo, como suele suceder con los cambios largamente pendientes - típicamente cambios en el esquema de base de datos que requieren base de datos de nuestra aplicación para poner a cero y no queremos hacer eso en los servidores de prueba en este momento porque el control de calidad se encuentra en el medio de los escenarios. Mientras más tiempo permanezca una lista de cambios, es más probable que un trabajo no relacionado toque uno de los mismos archivos, 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 configuración valga la pena por completo.

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