(Página creada con «Existe un paquete, git-svn, que agrega al comando Git, la capacidad de trabajar con repositorios remotos SVN, dependiendo de la estructura que tenga el repositorio SVN a mi...») |
(→Branches y Tags en Git) |
||
Línea 43: | Línea 43: | ||
En Git el código no está organizado en directorios como en los esquemas (a) y (b) de SVN antes mencionados, sino que para el usuario se ven como (c). Para acceder a un branch determinado o a un tag se usa checkout: | En Git el código no está organizado en directorios como en los esquemas (a) y (b) de SVN antes mencionados, sino que para el usuario se ven como (c). Para acceder a un branch determinado o a un tag se usa checkout: | ||
git checkout nombre_tag_o_branch | git checkout nombre_tag_o_branch | ||
+ | |||
+ | Checkout altera, crea y borra los archivos que sea necesario para que el usuario vea el branch o tag (o commit) seleccionado. Para saber en que branch se está actualmente se puede usar el comando: | ||
+ | git status | ||
Por convención el branch master es la línea principal de desarrollo (como el trunk en SVN). | Por convención el branch master es la línea principal de desarrollo (como el trunk en SVN). |
Existe un paquete, git-svn, que agrega al comando Git, la capacidad de trabajar con repositorios remotos SVN, dependiendo de la estructura que tenga el repositorio SVN a migrar, se puede usar este comando directamente o desde un script que simplifique la tarea.
Los repositorios SVN se estructuran en directorios y hay distintos esquemas para estructurarlos, el libro "Control de versiones con Subversion" recomienda 2 posibles esquemas [1].
Estos esquemas reservan un directorio para:
Los esquemas (a) y (b) son los recomendados por el libro: a. Para repositorios que contienen un único proyecto:
/ trunk/ branches/ tags/
b. Para repositorios con múltiples proyectos:
/ paint/ trunk/ branches/ tags/ calc/ trunk/ branches/ tags/
Pero como no hay ninguna restricción técnica para hacerlo de otra forma, uno podría organizar su repositorio como quisiera. Por ejemplo poniendo todos los archivos del proyectos sueltos:
c. Forma desprolija con los archivos sueltos:
/ main.c Makefile funcs.c funcs.h
Sin embargo en este ultimo formato es imposible tener branches y tags.
Git conceptualmente es similar, existen branches (ramificaciones) donde se almacenarán modificaciones que hagan que el proyecto diverja respecto de la versión de referencia. Y tags que marcan versiones con nombre del proyecto. Sin embargo la implementación es muy distinta.
En Git el código no está organizado en directorios como en los esquemas (a) y (b) de SVN antes mencionados, sino que para el usuario se ven como (c). Para acceder a un branch determinado o a un tag se usa checkout:
git checkout nombre_tag_o_branch
Checkout altera, crea y borra los archivos que sea necesario para que el usuario vea el branch o tag (o commit) seleccionado. Para saber en que branch se está actualmente se puede usar el comando:
git status
Por convención el branch master es la línea principal de desarrollo (como el trunk en SVN).
Si bien el esquema (c) es el más desprolijo y no es para nada recomendable, es el más fácil de migrar a git: