Cómo usar las ramas de Git para estructurar su proyecto de programación

Las películas y la televisión retratan la programación como una actividad frenética Hollywood Hacks: el mejor y el peor pirateo de películas Hollywood Hacks: el mejor y el peor pirateo de películas Hollywood y el pirateo no se llevan bien. Si bien la piratería en la vida real es difícil, la piratería de películas a menudo implica simplemente golpear con el teclado como si sus dedos estuvieran fuera de moda. . El temporizador de una bomba cuenta atrás, y el compañero nerd que era una carga hasta ese momento trabaja febrilmente en una computadora portátil. El código vuela por la pantalla hasta que presiona la tecla de retorno final con un resultado satisfactorio. charla! El temporizador se detiene y todo vuelve a estar en el mundo. Pero la programación no es nada de eso. Incluye documentos de diseño, maquetas de IU y revisiones de código. Y más que nada implica prueba y error, especialmente si eres un principiante (como yo).

Ahora, es posible que ya esté convencido del valor de mantener sus proyectos de codificación en control de código fuente. ¿Qué es Git y por qué debe usar el control de versiones si es desarrollador? Como desarrolladores web, muchas veces tendemos a trabajar en sitios de desarrollo local y luego cargamos todo cuando terminamos. Esto está bien cuando solo eres tú y los cambios son pequeños ... Cometer todo este ensayo y error en su repositorio hará que sea un proyecto grande y desordenado, con muchas revisiones. La mayoría de las confirmaciones que realice contendrán cosas que están rotas, entonces, ¿por qué guardarlas? El imbécil rama la función puede ayudar a mantener todo este código desordenado alejado de las cosas que sabes que funcionan.

En este artículo, veremos qué significa ramificar su código, cómo hacerlo y las formas de administrar las actualizaciones “principal” rama.

Crear una rama de Git

Aprendimos de nuestra introducción al control de origen Administre el control de versiones de su archivo como un programador con Git Administre el control de versiones de su archivo como un programador Con Git Programmers creó sistemas de control de versiones (VCS) para resolver problemas de control de versiones de archivos. Echemos un vistazo a los conceptos básicos del control de versiones con el sistema superior de hoy, Git. que puede crear un nuevo repositorio con el siguiente comando en una terminal:

git init

Cuando hace esto, crea un directorio oculto en su ruta actual, llamado “.git.” Si no puede verlo, consulte algunos de nuestros artículos anteriores sobre cómo ver archivos ocultos y carpetas en Windows 10, 8.1 y 7 La manera fácil de mostrar archivos y carpetas ocultos en Windows 10, 8.1 y 7 ¿Necesita ver archivos y carpetas ocultos en Windows? Aquí le mostramos cómo mostrarlos en Windows 10, 8.1 y 7 para que no se le oculte nada. archivos Ocultar y buscar cualquier archivo en Mac OS X Ocultar y buscar cualquier archivo en Mac OS X No hay una forma directa de ocultar o revelar rápidamente archivos ocultos en Mac OS X como en Windows, pero es posible. . Este directorio contiene toda la información necesaria para mantener el historial de revisión de sus archivos. Una vez que configura su administrador de archivos para mostrar archivos ocultos, puede abrir la carpeta .git y ver una serie de subdirectorios. Uno de estos se llama “refs” (se muestra en la imagen de abajo) y su “cabezas” El subdirectorio contiene listados para todas las ramas en su proyecto. Al principio tendrás solo uno, doblado “dominar.”

El directorio de referencias mantiene un registro de la rama, pero no la rama en sí. Al menos, no la rama en la que estás actualmente usando. Esos archivos se guardan en el directorio de trabajo (“~ / Temp / post-programación-git-branch” en el ejemplo anterior) para que pueda acceder a ellos de manera normal. Haciendo exactamente eso, creamos nuestro primer archivo (llamado “first-file.txt”) en el directorio de trabajo, es decir. fuera de el directorio .git Verifique esto usando los comandos de confianza de la introducción anterior al artículo de git Administre su versión de archivo como un programador con Git Administre su versión de archivo como un programador Con Git Programmers creó sistemas de control de versión (VCS) para resolver problemas de control de versión de archivo. Echemos un vistazo a los conceptos básicos del control de versiones con el sistema superior de hoy, Git. :

Podemos ver ahora que el directorio de trabajo tiene dos archivos, el que confirmamos y otro creado automáticamente por git (contiene el mensaje de confirmación que acabamos de ingresar).

Ahora, creemos una nueva rama de git llamada “pruebas”:

prueba de rama git

Echando un vistazo a la sucursal y trabajando en ella

Podemos emitir el comando anterior sin ningún nombre para obtener una lista de todas las ramas, así como cuál estamos usando actualmente (es decir, cuál es “controlado”):

Ahora, si examinamos la estructura del directorio, veremos “.git / refs / heads” ahora tiene dos archivos, uno para cada uno “dominar” y “pruebas.”

Cada uno de estos es una lista de los commits que componen la rama. Por ejemplo, si examinamos el “dominar” rama con el “registro de git” comando, podemos ver una línea para cada una de las confirmaciones realizadas en esa rama.

El proceso de “el registro de salida” una rama significa que los cambios que realice en los archivos serán parte de esa rama, pero no de otras ramas. Por ejemplo, supongamos que revisamos la rama de prueba de git con el siguiente comando:

prueba de pago git

Luego agregamos una línea de texto a first-file.txt, por supuesto, luego lo confirmamos. Si vuelve a la rama maestra, encontrará que el archivo todavía está en blanco (el gato El comando muestra el contenido de un archivo en el terminal):

Pero volviendo al “pruebas” rama, el archivo todavía tiene el texto agregado:

Pero todo lo que vemos en el directorio correcto es el archivo único “first-file.txt.” ¿Dónde están estas dos versiones alternativas del mismo archivo? El directorio .git tiene en cuenta estos cambios, pero no de la forma que cabría esperar..

Cómo Git almacena cosas

Si examinara un repositorio para otros sistemas de control de versiones como Subversion, encontraría que mantienen una copia por revisión para cada archivo individual. Esto significa que si tiene un repositorio de un archivo, luego cree dos ramas, el repositorio contiene dos copias diferentes de ese archivo. De hecho, en realidad usas “copia svn” como el comando para crear una rama en Subversion! Por otro lado, git opera sobre el concepto de “cambios.”

El resultado de lo anterior nos dice todo el contenido de “el maletero” (Versión de SVN de “dominar”) ha sido copiado. Una mirada en un administrador de archivos confirma esto:

los “.git / objetos” El directorio es lo que contiene todos estos pequeños cambios, y cada uno se rastrea con una ID. Por ejemplo, en la imagen a continuación, verá archivos con nombres largos de estilo ID. Cada uno vive en una carpeta con dos caracteres hexadecimales (8c y 8d abajo).

Juntos, estos nombres de carpeta y archivo forman la ID para un cambio particular (en realidad, un hash SHA1). Puede explorar sus contenidos usando el git cat-file mando. Según sus fechas modificadas, podemos ver el comienzo “8d” vino primero, y no muestra nada. Mientras que el que comienza “8c” contiene la línea de texto que agregamos al archivo en el “pruebas” rama.

La conclusión es que las ramas git (incluido el valor predeterminado “dominar”) no están separados “carpetas” que contiene copias de archivos. Más bien, son listas de cambios realizados en los archivos a lo largo del tiempo. Esto es más eficiente en cuanto al almacenamiento, pero el resultado es el mismo. Todo lo que haces (¿se rompe?) En una rama de git permanece allí hasta que lo fusionas.

Estrategias para volver a fusionar con la rama principal (¿Eliminar o No eliminar?)

Supongamos que tiene un proyecto existente con una serie de archivos, que luego ramificó en “pruebas,” e hice un trabajo en ello. Ahora desea que esos cambios vuelvan a “dominar” rama. Puedes hacer lo siguiente desde el “dominar” rama:

prueba de fusión git

Siempre que no haya conflictos, el cambio que consiste en el nuevo texto será aplicado a “dominar.” El resultado es “first-file.txt” será idéntico en ambas ramas. Sin embargo, nunca hubo realmente alternativas versiones del archivo.

Ahora viene la pregunta, ¿qué hacer con la rama? Hay dos estrategias comunes para tratar con sucursales.

1. Una es mantener una rama git como “pruebas” para jugar (como se muestra arriba). Intenta algunas cosas y, si puede hacer que funcionen, combine los cambios nuevamente en “dominar.” Entonces puede finalizar el trabajo en esa rama, o incluso deshacerse de ella por completo. Esto significa que tu “dominar” es la versión más estable del código, porque solo debe contener cosas que sabes que funcionan. También puede pensar en este enfoque como usar “ramas características.” Esto se debe a que su propósito es refinar una (o varias) adiciones específicas al código.
2. Un enfoque diferente es hacer todo su trabajo principal en el “dominar” rama, haciendo compromisos en el camino. Una vez que esté satisfecho con la funcionalidad, crea una rama dentro de la cual hará la corrección de errores y similares. Esto resulta en más de un “rama de liberación” (se muestra a continuación), ya que terminan con el lanzamiento. También significa tu “dominar” la rama es típicamente la versión más inestable de tu código.

Use el método que sea mejor para usted

El primer enfoque aquí es más común cuando se trabaja con git. Sus otras características (específicamente etiquetas) hacen que sea fácil marcar una instantánea particular del código como “estable.” También se presta mejor a proyectos más grandes y colaborativos. Pero cuando trabaje en sus propios proyectos personales, siéntase libre de usar el que tenga más sentido para usted. Lo mejor de usar git es que captura todos sus cambios, por lo que siempre puede regresar y encontrar algo. Y organizar su proyecto con ramas git hace que sea un poco más fácil de hacer.

¿Cómo aborda las sucursales en sus proyectos? ¿Los usas para experimentar y luego los tiras a la basura? ¿O representan una historia detallada de su trabajo en el proyecto??

Háganos saber a continuación en los comentarios si tiene alguna forma inteligente de tratar con sucursales en sus proyectos git!