¿Presionas cada compromiso?

Me gustaría, si alguien pudiera darme más detalles sobre cómo trabajar con repositorios remotos y git. No he trabajado con repositorios remotos, todavía.¿Presionas cada compromiso?

Para el repositorio local, se realizan cambios más pequeños que pueden no ser muy revolucionarios. ¿Qué se envía al repositorio remoto? Cada compromiso local? ¿O el trabajo general que se hizo, que luego se fusionó con los trabajos generales de otros? Creo que el registro del repositorio remoto debe ser confuso, si todos presionan cada confirmación.

Fuente

2012-05-12 rynd

Otra gran ventaja de un repositorio remoto (o centralizado, si no se usa Git) es la copia de seguridad, en caso de que el almacenamiento local esté dañado. Desde la perspectiva de la copia de seguridad, los empujes frecuentes minimizan la posible pérdida de datos. –

Empujar y tirar desde el repositorio remoto no es tan importante como sus confirmaciones locales. Por lo general, empujar y tirar varias veces al día es suficiente. Como dijo @earlonrails, los empujes más frecuentes significan menos probabilidad de cambios conflictivos, pero por lo general no es tan importante.

Piénselo de esta manera, al comprometerse con su repositorio local, básicamente está diciendo "Confío en este código. Está completo. Se ejecuta. Lo he probado. Estoy listo para que otras personas puedan verlo". Si desea ingresar al repositorio remoto después de cada confirmación, está bien, pero siempre que lo haga de manera regular, realmente no importa.

Los repositorios locales se dedican al seguimiento de los cambios para proteger el trabajo que realiza. Los repsitorios remotos son para distribuir el trabajo a todos sus compañeros de equipo y hacer un seguimiento de los cambios de todos. Tus compañeros de equipo necesitan acceder a tu código, pero generalmente no es urgente y puede esperar hasta el final del día o cuando quieras.

Fuente

2012-05-12 16:04:40 acattle

+11

No estoy de acuerdo con su afirmación sobre la integridad de las confirmaciones locales. Muy a menudo hago commits de trabajo en progreso localmente en mi sucursal, o commits ad-hoc, con la intención de volver a basar y limpiar (aplastar, reescribir, reordenar, etc.) mi rama antes de empujar. En mi humilde opinión, es su impulso a un control remoto que expresa un compromiso con la calidad y la finalización de su conjunto de cambios. –

¿Qué sucede si la máquina de desarrollo que tiene el repos local se colgó? –

En los viejos tiempos antes de github, creo que era la mejor práctica comprometerme con el control de versiones a menudo. También evita que se pierda el código si el ordenador portátil dev/la máquina se cuelga. pero tu No presiono eso a menudo desde que comencé a usar git. –

Puede empujar al control remoto a su conveniencia. El único problema con empujar un puñado de commit a la vez es que puede necesitar combinar más conflictos con más archivos afectados. Si eres nuevo en git, recomiendo git ready.

Los mandos a distancia funcionan igual que el repositorio local, pero tiene que jugar bien con los demás. Si otras personas presionan a distancia antes de presionar. Entonces sus cambios tendrán que ser retirados por usted antes de que pueda empujar. Si ambos tocan el mismo archivo, dado que su cambio fue primero, deberán combinar los dos cambios.

Fuente

2012-05-12 16:00:39 earlonrails

"tienes que jugar bien con los demás" - Ya veo, esa es la esencia de este tema. Pocas personas se interesan en ver cada pequeño cambio que hice. – rynd

En la medida de lo posible, recomiendo una herramienta de revisión de código, git diff y o gitx y gitk. Aquí hay una publicación sobre las herramientas de revisión de código para git. http://stackoverflow.com/questions/3713103/best-code-review-tool-for-git/10434975#10434975 – earlonrails

Intento presionar cada confirmación local como sea posible (utilizo Git). Rara vez tengo 2 o más confirmaciones localmente. De lo contrario, existe un riesgo de conflicto que no es tan agradable de resolver.

Prefiero usar rebase en lugar de fusionar, para mantener el historial más lineal. Si tengo 2 commits A y B (B es más viejo) localmente, y B entra en conflicto con los próximos cambios, después de resolver coflicts en rebase tengo que verificar B, verificar compilación, quizás ejecutar pruebas, y solo luego cambiar a A y empujar todo .

Es por eso que prefiero impulsar todo lo que tengo tan pronto como sea posible.

Fuente

2012-05-12 16:06:42

¿Está * realmente * trabajando siempre con el mismo código que otras personas, por lo que una o dos confirmaciones son suficientes para introducir un conflicto que debe abordar? –

No siempre, pero periódicamente sucede tal situación (no puedo decirlo muy a menudo), y esto es molesto, así que prefiero evitarlo. El 90% de todos los conflictos son causados por importaciones de Java. –

Respuesta

Cuestiones relacionadas