Estructura de un repositorio Git

Lo siento si esto es un duplicado, lo miré.

Nos mudamos a Git. En Subversion, estoy acostumbrado a tener carpetas \ trunk, \ branch y \ tags.

Con Git, cambiar entre ramas reemplazará el contenido del directorio de trabajo, así que ¿estoy en lo cierto al suponer que la forma en que solíamos trabajar simplemente no se aplica con Git?

Supongo que tendría una carpeta de repositorio con quizás un gitignore y readme.txt, luego las carpetas para los proyectos que componen el repositorio, y eso es todo.

Tendrá "troncal", ahora llamado "maestro", tendrá "ramas" ahora llamadas "cabezas" y tendrá "etiquetas", todavía llamadas "etiquetas", pero no serán carpetas , serán " refs ", etiquetas a las revisiones que viven en un espacio de nombres separado dentro del repositorio.

Subversion y Git tienen diferentes formas de hacer ramificaciones. El modelo básico de subversión es tener un árbol de directorios con una línea de tiempo global única y si desea bifurcar, copie un subárbol en otro directorio.

Por otro lado, Git tiene un árbol de directorios con revisiones que cada uno define sus padres, pero cada revisión puede tener varios padres (una combinación) y varios hijos (ramas). Entonces, en lugar de tener directorios para sucursales, obtienes revisiones creadas independientemente. Las "referencias" son solo nombres asociados con la última revisión para una "rama" dada.

Esta diferencia es fundamental para el control de versiones distribuidas. Git (y otros sistemas distribuidos) no tienen ninguna autoridad central para mantener el historial lineal, por lo que las revisiones se pueden crear de forma independiente en múltiples repositorios sin conocerse entre sí y el sistema tiene que acomodarlos. Resulta que la generalización hace que la ramificación y la fusión sean mucho más fáciles en general.

Tenga en cuenta que en Git, las revisiones no están en ninguna rama. Simplemente son y las ramas los contienen. Pero una vez que se fusiona la rama, o se demuestra que está en un callejón sin salida, simplemente puede eliminar la "referencia" que la señala y olvidarse por completo (si descarta las pruebas antiguas, eventualmente se recolectarán con la basura git gc). Esto te ayuda a evitar que te sumerjan en viejos experimentos, ya nadie recuerda de qué se trataban.

Solo piense en Git como una vista 3D de los mismos datos que ve en 2D en SVN, es decir, con SVN ramifica su raíz y aparece como una copia que se muestra como una nueva carpeta en el árbol. Con Git, cuando se ramifica, aparece como una copia que se muestra como una "capa" en la parte superior de su árbol existente. Una vez que te das cuenta de que es bastante fácil conceptualizar la diferencia.

Con SVN, aún puede trabajar de la misma manera que Git: el cambio entre ramas reemplazará la vista única de la base de código con la vista ramificada, esto se aplica si usa el interruptor svn o el pago de git.

Obviamente, puede obtener una copia de una rama en SVN revisando la rama en su ubicación de carpeta, que es lo mismo que clonar un repositorio git en una ubicación diferente en su disco.

Lo mismo se aplica a las etiquetas: puede etiquetar una revisión de git, o puede hacer una rama para un lanzamiento. Las etiquetas SVN son las mismas que las ramas, su única convención es que se llaman 'etiquetas'. También podría etiquetar (bueno, registrar el número de revisión) de un repositorio SVN para obtener una instantánea de un lanzamiento.

Las diferencias entre git y svn tienen más que ver con la forma en que se realizan los registros y las salidas, no con los fundamentos del control de código fuente. La vista del código puede ser diferente (nunca verá una sola vista del árbol de código que incluya ramas en git, y puede ramificar un repositorio parcial en SVN, pero estas son diferencias menores)