Entonces, ¿qué es mejor, usar git-p4 o simplemente deslizar un directorio .git en el directorio de trabajo y tener forzosamente que ignorarlo?

Question

Sé que esto tiene comeup antes, pero había pocas experiencias personales cotidianas en los mensajes que vi. Solo un par de respuestas. Me encantaría saber de personas que usan git-p4, o han usado git "under the covers" en un repositorio de Perforce, o preferiblemente ambos.
Y para las personas que solo usan git debajo de otro control de versión, me encantaría saber cómo lidiar con la notificación del control de la versión principal de los cambios. Específicamente, con git/forzosamente, cuando haya terminado y esté listo para enviar los cambios al servidor forzado, ¿cómo lidiará con decir forzosamente qué cambios ha habido?
He analizado los enganches post-commit con git, pero me gustaría escuchar cualquier otra idea.

Answer 1

Utilicé git-p4 en el trabajo. Es un puente bidireccional, así que si quieres usar git y luego volver a comprometer tus compromisos locales en p4, es una buena forma de hacerlo. Sin embargo, la política de nuestra oficina tenía una cultura de un pequeño número de confirmaciones masivas en lugar de muchas pequeñas, por lo que tuve que volver a establecer todos los cambios en un solo parche antes de volver a ingresar en p4. Me hubiera gustado mantener la historia local bien detallada, pero volver a cometer de un solo golpe, pero nunca pude lograrlo.

---

Apropos change notification. git-p4 crea parches para cada registro desde el último y los envía como conjuntos de cambios por separado. Esto refleja la historia de la rama principal en la que estás trabajando en tu repositorio de git.

Answer 2

Uso git con TFS y he elegido ir con la Opción 2: deslizo el directorio .git y hago que TFS lo ignore. Hago esto por la misma razón que @Noufal, tenemos una cultura aquí de "un gran compromiso" frente a las decenas de pequeños commits que hago en Git. Como solo me comprometo con TFS una o dos veces al día, no vale la pena que me meta con ganchos post-commit o rebases o cualquier otra cosa.

Answer 3

Supongo que realmente depende del diseño de su repositorio forzado - si está trabajando en una sección relativamente pequeña de él, entonces probablemente solo vaya a soltar el directorio .git directamente. Es el camino menos de resistencia por mucho y lo he utilizado con éxito en proyectos más pequeños.

Dicho esto, he luchado con este enfoque en repositorios más grandes, probablemente tanto con el flujo de trabajo donde trabajo como la gestión general de todo. Todavía tengo que echarle un vistazo a git-p4, pero es algo que me interesa investigar más.

Answer 4

La forma en que lo hago es tener una rama principal y ramas de función en git, y luego usar git diff --name-only master en una rama de características para averiguar qué archivos he cambiado para una función en particular. Luego verifico esos archivos en una lista de cambios de Perforce y los envío.

... bueno, más o menos ... :) En la práctica, usamos Code Collaborator para las revisiones de código, por lo que reviso los archivos en algún momento entre el inicio de la función y el envío de los archivos para la revisión del código (realmente no importa mucho cuando). Luego verifico antes de la revisión del código que tengo todos los archivos que debería tener usando el comando git anterior. (En realidad, porque estoy paranoico, ahora hago un git clean -xdf en mi directorio de origen y hago un Perforce "Reconcilie Offline Work" para verificar dos veces lo que voy a enviar. Luego hago una reconstrucción completa de todo el proyecto. Romper la construcción es vergonzoso, después de todo.) Una vez que todas las revisiones terminaron, simplemente envié la lista de cambios como siempre.

Es un poco faff, de verdad, pero ahora no es tan malo, ya me he acostumbrado, y es mucho mejor que usar Perforce con commits masivos, y trabajar efectivamente sin ningún tipo de control de versión por días a la vez :)