version-control - usados - github
Mejores prácticas de control de versiones (7)
Acabo de pasar al control de versiones el otro día, y después de una mala experiencia con Subversion, me cambié a Mercurial y hasta ahora estoy contento con él.
Aunque comprendo y aprecio la idea del control de versiones, realmente no tengo ninguna experiencia práctica con él.
En este momento, lo estoy usando para un par de sitios web en los que estoy trabajando, y un par de preguntas han llegado a mi mente:
- ¿Cuándo / con qué frecuencia debo comprometerme? Después de cualquier cambio importante, si funciona o no? Cuando termine por la noche? ¿Solo cuando llega a su siguiente iteración estable? Después de cualquier corrección de errores?
- ¿Me desviaría cuando quisiera, por ejemplo, cambiar el diseño de un menú, y luego volver a fusionar?
- ¿Debo ramificar? ¿Cuál es la diferencia (solo para mí, un desarrollador solitario) entre la ramificación, la fusión, la clonación y la recuperación?
¿Algún otro consejo para un novato de control de versiones?
Hasta ahora, todos me han dado buenos consejos, pero muy orientados al equipo. Me gustaría aclarar:
En este momento, solo estoy usando VC en algunos sitios web que hago en el lateral. No es un trabajo totalmente independiente, pero a los efectos de VC, soy el único que realmente toca el código del sitio web.
Además, dado que estoy usando PHP en los sitios, no hay compilación que hacer.
¿Esto cambia sus respuestas significativamente?
¿Cuándo / con qué frecuencia debo comprometerme?
Probablemente obtendrás muchas respuestas contradictorias en este caso. Mi opinión es que debe confirmar los cambios cuando están funcionando, y cada confirmación (o registro) debe contener exactamente una "edición". Una "edición" es un conjunto atómico de cambios que se unen para corregir un error o implementar una nueva característica.
Existe la teoría de que debe verificar el código cada pocas horas, incluso si no está funcionando, pero en ese caso tendrá que estar trabajando en su propia sucursal; no quiere estar ingresando el código roto en su línea principal. o en una rama compartida.
La ventaja de registrar todas las noches es que tiene copias de seguridad (asumiendo que su repositorio está en una máquina diferente).
En cuanto a la ramificación:
- Debes tener línea principal que contenga siempre código de trabajo.
- debe tener una rama de desarrollo actual que contenga el código más reciente. Cuando esté satisfecho con esto (y haya pasado todas sus pruebas), debe volver a combinarlo con la línea principal.
- es posible que desee una rama que contenga la última versión publicada. Esto se puede usar para probar / depurar errores y liberar parches (in extremis).
Estas son las prácticas que sigo
Cada confirmación debe tener sentido: una corrección de errores (o un conjunto de errores relacionados entre sí), una característica nueva (pequeña), etc. La idea es que si necesita restaurar, sus reversiones caen en "límites" bien definidos
Cada compromiso debe tener un buen mensaje explicando lo que está cometiendo. Entra realmente en este hábito, te lo agradecerás más tarde. No tiene que ser detallado, unas pocas oraciones pueden hacerlo. Si está utilizando un sistema de seguimiento de errores, asociar un número de error con su confirmación también es extremadamente útil
Ahora que uso git y ramificación es increíblemente rápido y barato, tiendo a crear una nueva sucursal para cada nueva característica que estoy a punto de implementar. Nunca consideraría hacer esto para muchos otros VCSes. Por lo tanto, la ramificación depende del sistema que esté utilizando, su base de código, su equipo, etc., no hay reglas estrictas allí.
Prefiero usar siempre la línea de comandos y conocer directamente los comandos de mi VCS. La desconexión que puede causar una interfaz de usuario basada en GUI puede ser una molestia e incluso dañina. Controlar su código fuente es muy importante, vale la pena entrar y hacerlo directamente. Pero eso es solo mi preferencia.
Copia de seguridad de su VCS. Realizo una copia de seguridad de mi repositorio local con Time Machine, y luego me dirijo a un repositorio remoto en mi servidor, y ese servidor también está respaldado. VCS por sí solo no es realmente una "copia de seguridad", sino que también puede disminuir como cualquier otra cosa.
Estoy de acuerdo con los demás en los tiempos de compromiso.
Con respecto a la bifurcación, generalmente bifurco solo cuando trabajo en algo que rompe lo que otros están haciendo o cuando un parche debe pasar a producción en un archivo que ya tiene cambios que no deberían ir a producción. Si solo eres un desarrollador, entonces el primer escenario realmente no se aplica.
Utilizo etiquetas para administrar lanzamientos: la etiqueta "producción" siempre está asociada con el código de producto actual, y cada lanzamiento está etiquetado con "lanzamiento-YYYYMMDD". Esto le permite retroceder si es necesario.
La mayoría de las preguntas sobre las que está preguntando dependen principalmente de con quién está trabajando. Si eres un desarrollador solitario, no debería importar mucho, ya que puedes hacer lo que quieras. Pero si está en un equipo en el que tiene que compartir su código, entonces debe discutir con los miembros de su equipo cuál debe ser el código de conducta , ya que compartir los cambios entre sí puede ser complicado a veces.
La discusión sobre el código de conducta no necesita ser larga, puede ser muy breve; siempre que todos estén en la misma página sobre cómo usar el repositorio compartido entre los programadores del equipo. Si desea usar las funciones más avanzadas de Mercurial, como el picking cherry o las colas de parches, intente usarlas para que no afecten a los miembros de su equipo de manera negativa, como volver a basar en un repositorio público.
Recuerde que el control de versiones debe ser fácil de usar para todos los integrantes del equipo, de lo contrario no se utilizará.
¿Cuándo / con qué frecuencia debo comprometerme? Después de cualquier cambio importante, si funciona o no? Cuando termine por la noche? ¿Solo cuando llega a su siguiente iteración estable? Después de cualquier corrección de errores?
Mientras se trabaja con un equipo, hay varios enfoques, pero la regla común es comprometerse temprano y con frecuencia . La razón principal por la que debe comprometerse a menudo es hacer que los conflictos de fusión sean más fáciles de manejar .
Un conflicto de combinación se pone simplemente cuando la fusión de un archivo que ha cambiado al menos dos personas no funciona porque se han editado en las mismas líneas. Si se aferra a un compromiso que implica un cambio muy grande con varias líneas de cambios en varios archivos, será muy difícil de administrar para el receptor gestionar los conflictos que puedan surgir. El conflicto de fusión se vuelve aún más difícil de manejar si dicho conjunto de cambios se mantiene durante demasiado tiempo.
Hay algunas excepciones a la regla de cometer con frecuencia y una es cuando se produce un cambio importante . aunque si tiene la capacidad de cometer localmente (lo que está haciendo en Mercurial y git inherentemente) podría cometer cambios de última hora. Siempre que arregles lo que se rompió, deberías enviarlo hacia arriba al repositorio compartido cuando hayas arreglado tu propio cambio de ruptura.
¿Me desviaría cuando quisiera, por ejemplo, cambiar el diseño de un menú, y luego volver a fusionar? ¿Debo ramificar?
Hay muchas estrategias de bifurcación para elegir (hay un artículo de Streamed Lines de 1998 que tiene una lista exhaustiva de patrones de estrategias de bifurcación ) y cuando las creas para ti, debería ser un juego abierto para ti. Sin embargo, cuando trabaje en equipos, es mejor que discuta abiertamente con el equipo si necesita o no filtrarse. Cuando tenga la necesidad de dividirse, debe hacerse las siguientes preguntas:
¿Estarán mis futuros cambios rompiendo el trabajo de otros?
¿Tendrá mi equipo un impacto negativo directo de los cambios que haré hasta que termine?
¿Es mi código el código desechable?
Si la respuesta es afirmativa en alguna de las preguntas anteriores, probablemente debería bifurcarse públicamente o guardarla para usted (ya que puede hacerlo en Mercurial de varias maneras). Primero debe discutir con su equipo sobre cómo ejecutar todo el endavour para ver si hay alguna otra forma de hacerlo y si va a fusionar sus cambios nuevamente, a veces hay factores en juego donde no hay necesidad de hacerlo. bifurcación (esto se relaciona principalmente con cuán modular es el código).
Cuando decida dividirse, prepárese para manejar un conflicto de fusión. Es lógico asumir que el que creó la rama e hizo los compromisos para poder fusionarla de nuevo en la "rama principal". En estos momentos, sería fantástico que todos los miembros del equipo hicieran comentarios de confirmación relevantes.
Como nota al margen: escribes buenos comentarios de confirmación, ¿verdad? ¿¡CORRECTO!? Un buen comentario de confirmación por lo general explica por qué se realizó ese cambio en particular o en qué característica estaba trabajando el conmutador en lugar de un tipo de comentario no anónimo "Hice una confirmación". Esto hace que sea más fácil para quien maneja el gran conflicto de fusión descubrir qué cambios de línea se pueden sobrescribir y cuáles mantener mientras se realiza el historial de revisiones.
Los tiempos de compilación o los tiempos de compilación, más bien, a veces juegan en la discusión de rama que pueda tener. Si su proyecto tiene un tiempo de construcción lento, puede ser una buena idea usar una estrategia de estadificación en sus sucursales. Esta estrategia tiene en cuenta que todos los desarrolladores deben integrarse en una "línea principal" y los cambios aprobados se elevan (o "promueven") a la siguiente etapa, como las líneas de prueba o de lanzamiento. Se ilustra clásicamente con nombres de etiquetas para software de código abierto como este:
main -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-> ...
/ / /
test o-----------o--------------o---------> ...
1.0 RC1 / 1.0 RC2 2.0 RC1
release o----------------------> ...
1.0
El punto con esto es que los probadores pueden trabajar sin ser interrumpidos por los programadores y que existe una línea de base conocida para aquellos que están en la administración de versiones. En el control de versiones distribuido, las diferentes líneas pueden ser repositorios clonados y puede verse un poco diferente, ya que los repositorios comparten el gráfico de control de versiones. El principio sin embargo es el mismo.
En cuanto al desarrollo web, prácticamente no hay tiempos de construcción. Pero la bifurcación en etapas (o al etiquetar las revisiones de su versión) se vuelve más fácil de revertir si desea corregir un error difícil de localizar.
Sin embargo, otra cosa entra en juego y ese es el tiempo que toma implementar el sitio. Las herramientas de control de versiones en mi experiencia son muy malas en la gestión de activos. El manejo de activos de arte que son en total hasta varios GB generalmente es un gran problema en el manejo de Subversion (más aún en Mercurial). Es posible que los activos requieran que usted los maneje de otra manera que consuma menos tiempo, como colocarlos en un espacio compartido que se sincroniza y realiza una copia de seguridad de una manera tradicional (los activos de arte generalmente no se trabajan simultáneamente con los archivos de código fuente).
¿Cuál es la diferencia (solo para mí, un desarrollador solitario) entre la ramificación, la fusión, la clonación y la recuperación?
Los conceptos de ramificación y mantenimiento de repositorios remotos están más cerca ahora que con las herramientas de control de versiones centralizadas. Casi se podría considerar que son la misma cosa. En Mercurial (y en git) puedes "ramificar" ya sea por:
Clonando un repositorio
Creando una rama nombrada
Crear una rama con nombre significa que estás creando una nueva ruta en el gráfico de versiones para el repositorio en el que lo estás creando. Crear un repositorio clonado significa que está copiando el repositorio de origen en una nueva ubicación y creando una nueva ruta en el gráfico de versiones del repositorio clonado. Ambas son dos implementaciones diferentes de ramificación como concepto general en el control de versiones.
En la práctica, la única diferencia entre los dos métodos que debe preocuparte es el uso. Clona un repositorio para tener una copia del código fuente y tiene un lugar para almacenar sus propios cambios y crea sucursales con nombre cuando quiera hacer pequeños experimentos por sí mismo.
Dado que navegar por las sucursales es un poco peculiar para aquellos que están acostumbrados a una línea recta de confirmaciones, los usuarios avanzados saben cómo manipular sus versiones, por lo que el historial de versiones está "limpio" con, por ejemplo, la selección de cerezas o la rebase . Por el momento, git docs en realidad explica la rebase bastante bien.
Me comprometo cuando termino un trabajo y solo si está funcionando. Es una mala práctica comprometerse en un lugar donde otras personas usan el código.
La ramificación es algo sobre lo que la gente discutirá. Algunas personas dicen que nunca se ramifican y solo tienen interruptores para que algo funcione o no. Haz lo que te sientas más cómodo pero no te ramifiques solo porque puedas. Utilizo Branching y Branch cuando estoy trabajando en una parte importante del trabajo donde, si por error cometí un código roto, no afectará a los demás.
P: ¿Cuándo / con qué frecuencia debo comprometerme? Después de cualquier cambio importante, si funciona o no? Cuando termine por la noche? ¿Solo cuando llega a su siguiente iteración estable? Después de cualquier corrección de errores?
R: Siempre que te sientas cómodo, me comprometo tan pronto como una unidad de trabajo esté terminada y funcionando (lo que no significa que la tarea completa tenga que estar terminada). Pero no debe cometer algo que no se compile (podría inhibir a otras personas en el equipo, si las hay). Además, no debe cometer cosas incompletas en el troncal si existe alguna posibilidad de que tenga que implementar una solución rápida o un pequeño cambio antes de completarla.
P: ¿Me desviaría cuando quisiera, por ejemplo, cambiar el diseño de un menú, y luego volver a combinar?
R: Solo si existe la posibilidad de que tenga que implementar una solución rápida o un pequeño cambio antes de completar su tarea.
Lo bueno de la bifurcación es que todas las confirmaciones que esté haciendo en la bifurcación seguirán estando disponibles para futuras referencias (si es necesario). También es mucho más simple y rápido que clonar el repositorio, creo ;-)
- actualizar antes de cada commit
- proporcionar comentarios de cometer
- cometer tan pronto como haya terminado algo
- no cometas nada que haga que el código en el repositorio no se compile o tenga errores
- actualizar cada mañana
- A veces se comunican verbalmente con colegas si hay algo importante que actualizar
- cometer código relevante para exactamente una cosa (es decir, corregir un error, implementar una función)
- No se preocupe por hacer compromisos muy pequeños, siempre y cuando cumplan con la regla anterior.
Por cierto, ¿cuál es la mala experiencia con Subversion?