Tutorial de ramificación Git para principiantes
- 938
- 134
- Carmen Casillas
La ramificación permite a GIT rastrear múltiples líneas de desarrollo. Esto esencialmente le permite tener múltiples versiones de su proyecto en desarrollo al mismo tiempo. Por ejemplo, muchos proyectos elegirán tener una rama maestra estable, mientras que las nuevas características o correcciones de errores se implementan en una rama de desarrollo o prueba. Una vez que los organizadores del proyecto están satisfechos de que los cambios realizados en la rama de desarrollo han alcanzado el nivel de madurez requerido, pueden optar por fusionar esos cambios en la rama maestra.
Para muchos proyectos más grandes, este ciclo a menudo se repetirá indefinidamente. El beneficio de implementar esta estrategia es que ayuda a reducir la introducción de errores en la versión principal de la base de código y, por lo tanto, reduce la aparición de errores y otro comportamiento adverso potencial en el software. Simultáneamente, permite a los desarrolladores probar nuevas ideas sin restricciones. Por lo tanto, pueden continuar contribuyendo creativamente al proyecto de manera eficiente.
En este tutorial aprenderás:
- Que es la ramificación
- Cómo crear ramas
- Cómo cambiar entre ramas
- Cómo eliminar ramas
- Cómo fusionar ramas
- Cómo administrar etiquetas
- Cómo usar etiquetas para realizar un seguimiento de los versiones
- Cómo trabajar con ramas y etiquetas en repositorios remotos
Tutorial de ramificación Git para principiantes Requisitos y convenciones de software utilizados
| Categoría | Requisitos, convenciones o versión de software utilizada |
|---|---|
| Sistema | Cualquier sistema operativo GNU/Linux |
| Software | Git |
| Otro | Acceso privilegiado a su sistema Linux como root o a través del sudo dominio. |
| Convenciones | # - requiere que los comandos de Linux dados se ejecuten con privilegios raíz directamente como un usuario raíz o mediante el uso de sudo dominiops - Requiere que los comandos de Linux dados se ejecuten como un usuario regular no privilegiado |
Creación de ramas
Examinemos un ejemplo rápido de cómo trabajar con sucursales, continuando con el proyecto GIT inicial que creamos en el tutorial Git anterior para principiantes. Primero, haga de ProjectName su directorio de trabajo actual. Ahora creemos una rama específicamente para trabajar en el proyecto Documentation for Out. Emitir el siguiente comando para hacer esta nueva rama.
$ Git Branch Docs
Ahora, echemos un vistazo a todas nuestras ramas.
$ GIT Branch
Simplemente emitiendo el rama git El comando como se muestra anteriormente muestra una lista de todas las ramas en nuestro repositorio Git. Notarás que se llama a la primera rama maestro por defecto. En nuestro caso, vemos el maestro rama y nuestra rama de documentos recién creado. Tenga en cuenta que la rama actual en la que estamos trabajando está marcada por * Y sigue siendo la rama maestra. Para comenzar a trabajar en la sucursal de Docs, necesitamos pagar la rama.
Cambio entre ramas
$ Git Documentos de checkout
Ahora que hemos revisado el documento rama, cualquier cambio que hagamos afectará esa rama solo y el maestro la rama permanecerá intacta y en el estado exacto en que estaba antes de revisar el documento rama.
Vamos a crear un readme.TXT Archivo para nuestro proyecto.
$ Echo "Este es un programa simple de Hello World que se creó durante un tutorial GIT."> Readme.TXT
Ahora que tenemos un archivo README descriptivo para la documentación, lo organicemos y lo cometamos tal como aprendimos a hacer en el Tutorial Git anterior para los principiantes.
$ git agregar lectura.txt $ git commit -m "agregó readme a la rama de documentos"
Ahora que hemos cometido el cambio en nuestra sucursal de Docs, podemos volver a la rama maestra revisándolo.
$ git checkout maestro
Adelante y enumere el contenido del directorio.
$ LS
Notarás que la rama maestra no tiene el readme.TXT Archivo porque en este momento solo existe en la rama de Docs. Esto demuestra cómo las dos ramas representan dos estados distintos de desarrollo.
Ramas fusionadas
Ahora, ¿qué pasa si sentimos que nuestra documentación está completa y lista para fusionar en la rama maestra?? Aquí es donde el comando de fusión git es útil. Ingrese el siguiente comando para fusionar la rama de los documentos en la rama maestra.
$ git fusion docs
Enumere el contenido del directorio y observe que la rama maestra ahora contiene el readme.archivo txt.
$ LS
Si emitimos
Log de $ git
Luego vemos que la historia del registro de las dos ramas también se ha fusionado.
Verifique el registro de git Eliminar ramas
Ahora que hemos completado nuestra documentación y fusionamos la rama de los documentos con la rama maestra, podemos eliminar con seguridad la rama de los documentos si queremos. Para hacerlo, simplemente agregue el -d Marcar al comando de rama git.
$ Git Branch -d Docs
Ahora solo tenemos una rama en nuestro proyecto nuevamente y refleja todos los cambios que hemos realizado a lo largo de él; incluyendo la adición de un archivo ReadMe.
Etiquetado
Es posible que queramos poder ver y referirnos fácilmente a una confirmación específica sin tener que usar su ID de confirmación. Para lograr esto, podemos usar el comando de etiqueta git para darle a un nombre memorable. En nuestro caso, nombrémonos a nuestro puño en eso, Nuestro segundo compromiso fuente Y nuestro último comodidad readme de modo que si alguna vez lo necesitamos en el futuro, podemos referirnos fácilmente a los compromisos donde inicializamos el proyecto, agregamos el código fuente y agregamos un archivo ReadMe respectivamente.
$ git etiqueta init abbda7da6f6257effc7da16766ffc464c4098a8e $ git etiqueta fuente 41dccee5478129094c3cbbcd08a26076a9aa370b $ git etiqueta readme
Puede notar que para el último comando no tuvimos que especificar una ID de confirmación. Esto se debe a que ese confirmación es nuestro jefe actual y el jefe actual se nombra de forma predeterminada si no se proporciona una ID de confirmación. Podríamos haber proporcionado la identificación de confirmación si quisiéramos, pero habría sido innecesario.
Si usamos el comando de etiqueta sin ningún argumento, nos dará una lista de todas las etiquetas que estamos usando.
Etiqueta de $ git
Si queremos ver todas las etiquetas junto con la otra información de confirmación, podemos emitir el comando de registro familiar:
Log de $ git
Etiquetado git De ahora en adelante, cuando queremos hacer referencia a estos compromisos, podemos usar sus etiquetas en lugar de sus identificaciones de confirmación. Al igual que podemos revisar una sucursal, también podemos ver una confirmación específica. Si decidiéramos que queríamos revisar nuestra primera confirmación, ahora podríamos verlo usando su etiqueta.
$ git checkout init
Desde este punto, si decidimos que queremos crear una nueva rama que fuera en una dirección completamente diferente a nuestro proyecto original, podríamos hacer eso haciendo algunos cambios aquí y emitiendo el comando Switch con el indicador -c seguido del nombre de la nueva rama. Similar al comando de pago, Switch cambia de ramas, pero con el indicador -c también puede crear simultáneamente una nueva rama.
$ git switch -c nuevo nombre de rama
También puede crear una nueva rama y cambiarla con el comando de pago de la siguiente manera.
$ git checkout -B nuevo nombre de rama
Use lo que prefiera, pero es importante tener en cuenta que de acuerdo con las páginas del hombre de Git, el comando Switch es experimental y su funcionalidad puede cambiar en el futuro.
Otras Consideraciones
Estamos utilizando un ejemplo muy simple para centrarnos en GIT en lugar del código que estamos administrando. Como resultado, las etiquetas que utilizamos reflejan un esquema de nomenclatura simple basado en la introducción de características. Sin embargo, los proyectos más grandes generalmente utilizarán las etiquetas como un medio para realizar un seguimiento de los versiones etiquetando compromisos que corresponden con números de punto de liberación específicos.
Por ejemplo, versión1.0,
versión 2.0 etc. También es importante tener en cuenta que cuando está presionando sus cambios a un servidor remoto, las nuevas ramas y las etiquetas no se presionan de forma predeterminada y deben ser presionadas específicamente utilizando los siguientes comandos.
$ Git Push Origin New_Branch_Name $ Git Push Origin Tag_name $ Git Push Origin -Tags
El primer comando presionará la rama especificada al servidor remoto, el segundo presionará la etiqueta especificada al servidor y el tercero empujará todas las etiquetas al servidor.
Otra cosa importante a tener en cuenta con respecto a los servidores remotos es que si ha clonado un repositorio remoto, la rama maestra ha clonado a su máquina local, pero no a las otras ramas.
Para ver todas las demás ramas en el Repo Remote Repo, el siguiente comando utilizando el -a bandera que muestra todas las ramas locales y remotas.
$ git rama -a
Una vez que consulte una rama remota, se descargará a su repositorio local y puede continuar trabajando localmente hasta que desee empujar los cambios que realizó a la rama de regreso al servidor.
Conclusión
Después de trabajar en los ejemplos anteriores, te animo a que continúes jugando con ramas y etiquetas hasta que trabajar con ellos comienza a sentirte intuitivo contigo. Si no tiene acceso a un repositorio remoto donde puede practicar cosas como presionar ramas, presionar etiquetas y verificar ramas remotas, entonces le animo a que cree una cuenta GitHub gratuita y seleccione la opción para crear un repositorio privado allí.
De hecho, recomendaría hacerlo incluso si tiene acceso a otros reposadores remotos. Si comete un error en su propia cuenta privada de GitHub mientras aprende, entonces no se hace un daño importante. Le recomendaría que comience a usar git en colaboración una vez que comience a sentirse súper cómodo con él.
Después de seguir este artículo y la Guía del Tutorial GIT para principiantes, ahora debe sentirse cómodo instalando GIT, configurar GIT, trabajar con sucursales, el concepto de versiones, etiquetar y usar GIT para trabajar con repositorios locales y remotos. Ahora tiene el conocimiento práctico para llevar la potencia y la eficiencia de GIT como un sistema de control de revisión distribuido. En lo que sea que esté trabajando, espero que esta información cambie la forma en que piense sobre su flujo de trabajo para mejor.
Tutoriales de Linux relacionados:
- Tutorial Git para principiantes
- Mint 20: Mejor que Ubuntu y Microsoft Windows?
- Cómo revertir las actualizaciones de Pacman en Arch Linux
- Tutorial introductorio para GIT en Linux
- Lista de las mejores herramientas de Kali Linux para pruebas de penetración y ..
- Manjaro Linux vs Arch Linux
- Sistema colgado de Linux? Cómo escapar a la línea de comando y ..
- Git: renombrar rama
- Cómo actualizar los paquetes de Ubuntu en Ubuntu 22.04 Jammy ..
- Lista de aplicaciones GUT GUI para Linux