Cómo utilizar un sistema de control de revisiones en general

Estoy planeando crear proyectos que serán un poco más grandes que mis proyectos antes, así que pensé que sería bueno usar un sistema de control de revisión como svn o git para realizar un seguimiento de todos los cambios, experimentar un poco con nuevas funcionalidades en el código sin riesgos, etc.

Ahora (además de la pregunta si debería usar svn o git), me estoy preguntando "cómo usar" dicho sistema en general.

Hasta ahora, he encontrado vocabulario como trunk , tags y branches (la combinación de palabras aparece a menudo en ese context). Pero no estoy realmente seguro de cómo trabajar realmente con ellos. Las tags parecen ser algo así como las versiones de lanzamiento (si no es así, corrígeme), pero no sé qué es lo que realmente pertenece al maletero o en una twig ; cuándo usar qué etc.

Durante mis investigaciones, también encontré una recomendación que generalmente debería crear una estructura de carpetas con las subcarpetas, twigs, tags y troncales para un nuevo proyecto. ¿También recomendarías esto? ¿O debería manejar el código fuente de un proyecto de una manera diferente?

¿Alguien puede tratar de explicarme esto?

El tema de los sistemas de control de versiones es probablemente demasiado grande para enseñar como parte de un sitio de preguntas y respuestas como Stack Overflow. Sin duda, puede hacer preguntas sobre ellos, pero "¿alguien puede decirme todo lo que necesito saber sobre ellos?" Probablemente no sea el lugar correcto.

Si le interesan los sistemas de control de versiones distribuidas, ya que ha mencionado git, debería echarle un vistazo a hginit.com . Mientras que el sitio describe a Mercurial , la mayoría, si no todos, también es cierto para git.

En cuanto a la recomendación de crear esas carpetas, eso depende completamente del sistema de control de versiones que decida usar.

Subversion usa "copys" a nivel de carpeta para crear twigs. Piense que tiene múltiples copys de su proyecto en el disco al mismo time, y que Subversion le permite combinar los cambios de una carpeta a otra y realiza un seguimiento de lo que ha fusionado, cuándo y en qué dirección.

Para DVCS ', eso no es necesario, ya que las sucursales se realizan de una manera diferente, y por lo tanto no necesita esos directorys.

El vocabulario que ha enumerado se puede resumir de la siguiente manera (tenga en count que dado que uso Mercurial, podría ser coloreado por su uso en ese sistema):

  • Tronco : tu línea de desarrollo principal. Si no tienes control de fuente, aquí es donde trabajarías todo el time.
  • Etiquetas : una label es un marcador liviano, piénselo como una nota de postín, que pegue en una determinada versión de su proyecto para que luego pueda responder la pregunta "Hmm, me pregunto cómo se veían todos los files fuente cuando lancé versión 1.0 "
  • Sucursales : una twig es una copy en paralelo del universo de su proyecto, posiblemente con cambios. Por ejemplo, cuando lanzó esa versión 1.0, puede crear esa label, pero también puede crear una twig. Luego, en el tronco, comenzaría a trabajar hacia la versión 2.0 o 1.1, y si necesita liberar un hotfix de 1.0 para corregir errores, entonces haría esas correcciones en esa twig 1.0.
  • Fusionar : cuando tiene varias sucursales, puede solicitarle a su sistema de control de versiones que lo ayude a realizar cambios en una twig en otra fusionándolas (los cambios o las twigs, esto difiere de un sistema a otro).
  • Changeset / revision – Casi sinónimo, significa un set de cambios que usted cometió al mismo time. Puede ser para corregir un error en particular o agregar una característica en particular. Un set de cambios puede contener cambios en muchos files, e incluso files nuevos, o la eliminación de files que ya no se necesitan.

El artículo de Wikipedia sobre control de revisiones también tiene mucha información útil.

El glosario de Mercurial también enumera una cantidad razonable de términos y su uso en Mercurial, y gran parte de esa información es válida para muchos sistemas de control de versiones.


De todos modos, aquí hay una manera típica (para mí de todos modos) de hacer un proyecto.

  • Usted crea el repository inicial del proyecto, con solo la twig principal (troncal en Subversion, por defecto en Mercurial, maestro? Creo en git)
  • Luego comienzas a trabajar en tu proyecto y te comprometes regularmente, creas una buena list de sets de cambios
  • En algún momento está listo para lanzar la versión 1.0, por lo que crea esa label, y crea una twig en ese punto llamada "1.0", y luego libera su software
  • Luego continúas trabajando, hacia la versión 1.1 o 2.0, dependiendo
  • En algún momento, tiene una list de errores encontrados en 1.0 por los clientes
  • Arreglas esos errores en trunk / default / master, por lo que la próxima versión grande al less tiene esas correcciones de errores, luego fusionas los cambios de nuevo en 1.0
  • Cuando se hayan solucionado todos los errores conocidos en 1.0, etiquete eso como 1.01 y libérelo
  • Y volvemos a trabajar en 2.0
  • Cuando 2.0 esté listo para lanzar, etiquete y bifurque de nuevo, etc.

Esta es solo una forma de hacerlo, hay muchos. Las personas te dirán cuál es su forma preferida si las preguntas y no diré que mi path es el correcto.

Puede comenzar a examinar http://www.infoq.com/articles/agile-version-control y http://nvie.com/posts/a-successful-git-branching-model/

También trunk-tag-branch es un pequeño esquema obsoleto, utilizado en svn. Los DSCM (mercurial, git) tienen soporte nativo para twigs y tags, por lo que no es necesario crear esos directorys explícitamente.

Expandiendo un poco en respuesta de Lasse V. Karlsen :

  • Con respecto a aprender a usar el control de revisiones , probablemente debería echar un vistazo a las "Preguntas relacionadas" que Stackoverflow encontró para usted.

    En mi opinión, The Git Parable, de Tom Prestn-Werner, de GitHub, enseña cómo y por qué uno debería usar el sistema de control de versiones (distribuidas) (describiendo cómo se podría haber creado DVCS como Git).

  • Acerca del model de bifurcación : si el sistema de control de versiones que está utilizando admite twigs ligeras, y puede fusionar sucursales bien y rápido, generalmente utiliza dos types de twigs en un flujo de trabajo típico:

    • twigs de larga vida como 'master' o 'main' o 'stable' (también conocido como 'trunk') donde va el trabajo actual hacia la nueva versión, 'next' o 'devel' o 'inestable' es donde pones el trabajo experimental ' maint 'o' maintenance 'es donde van las correcciones de errores a la última versión.
    • twigs de tema : cuando se comienza a trabajar en una nueva característica, es mejor ponerla en una twig separada de corta vida y generalmente no publicada. De esta forma puedes trabajar en alguna nueva característica experimental sin desestabilizar otro trabajo; permite trabajar en paralelo en muchas características no relacionadas.

HTH

El libro Subversion Red Bean tiene una agradable discusión sobre el tema.

Pragmatic Version Control es un buen libro, también.