Has usado Git individualmente por mucho tiempo, pero nunca has estado en un equipo que gestione un proyecto de manera colaborativa, pues antes de unirte a uno es importante que sepas ciertas técnicas Git, así evitarás perjudicar a los otros miembros del equipo y en este Post te enseñaré cuales son estas técnicas.
Partes
- Parte 1
- Parte 2 (Final)
Te voy a compartir técnicas esenciales o básicas de Git con las cuales te sentirás familiarizado antes de unirte a un equipo Git. Las he enumerado en un orden que por lógica seguirías para contribuir a un repositorio de un equipo, la importancia de cada paso es primordial, vamos con la lista.
Clonación: Comenzando en un equipo
Si has usado Git en proyectos personales, es posible que solo hayas iniciado un proyecto desde cero y lo hayas agregado manejando tus propios tiempos. Cuando estas trabajando sobre un código existente, el primer paso que debes hacer es clonar el proyecto a tu sistema local o computadora. Esto te permite trabajar sobre la copia clonada en tu computadora, sin afectar al proyecto original alojado en el repositorio del equipo.
Para clonar un repositorio puedes ejecutar el comando git clone, seguido de la ruta al repositorio.
|
1 2 3 4 |
# Clonar repositorio git clone /ruta/al/repositorio |
Si el proyecto no esta en el mismo sistema, puedes enviar SSH a un sistema remoto y clonarlo también:
|
1 2 3 4 |
# Clonar repositorio remoto git clone usuario@ip_sistema_remoto:/ruta/al/repositorio/remoto |
Y si estas clonando desde una fuente de Internet, sencillamente agrega la URL:
|
1 2 3 4 |
# Clonar desde una fuente de Internet o URL git clone https://github.com/nombredelusuario/nombre_del_proyecto.git |
Cuando clonas un repositorio, tienes la opción de elegir varios protocolos para conectarte a la fuente del proyecto. En el ultimo ejemplo he usado GitHub con el protocolo https.
Gestionar controles remotos en Git
Luego de clonar un repositorio, aún mantienes conexión directa al repositorio, esta conexión es un ejemplo de control remoto en Git. Un control remoto es como un puntero a otra copia del mismo repositorio. Cuando clonas un repositorio, se crea automáticamente un puntero origin (nombre abreviado del repositorio) que apunta a la fuente del proyecto.
Puedes ver una lista los controles remotos en un repositorio, ejecutando el siguiente comando:
|
1 2 3 4 |
# Ver lista de controles remotos en un repositorio git remove -v |
Para agregar un control remoto de la lista, puedes usar el comando git remote add:
|
1 2 3 4 |
# Agregar un control remoto git remote add nombre_del_control_remoto |
También puedes eliminar un control remoto con el comando git remote remove:
|
1 2 3 4 |
# Eliminar control remoto git remote remove nombre_del_control_remoto |
Y si deseas cambiar la dirección de un control remoto, puedes usar el comando set-url:
|
1 2 3 4 |
# Cambiar la dirección de un control remoto git remote set-url nombre_del_control_remoto nueva_direccion_remota |
Ramificación en Git
La mayor ventaja de Git sobre otros sistemas de control, es quizás la diversidad de funciones y opciones con las que cuenta, antes de pasar a la ramificación, veamos de manera rápida que es una rama en Git.
Una rama en Git es un punto que apunta a una confirmación en un repositorio, que a su vez apunta a un predecesor. Por ende una rama representa una lista de confirmaciones en orden cronológico. Cuando creas un rama, efectivamente crea solo un nuevo puntero a una confirmación. Sin embargo, en esencia, representa un nuevo camino para desarrollar el proyecto de manera independiente.
Por defecto Git usa la rama master y cualquier nueva confirmación se agrega a esta rama master.
El trabajo con ramas es necesario para que Git bifurque líneas de trabajo en un proyecto. Al mismo tiempo, puede haber muchos desarrolladores que están trabajando en diferentes partes o problemas del proyecto. Estas partes o problemas se trabajan en diferentes ramas para garantizar la separación lógica del nuevo código hasta la revisión y combinación del código.
Para verificar una lista de ramas existentes y la rama activa actual, puedes ejecutar el siguiente comando:
|
1 2 3 4 |
# Verificar la lista de ramas disponibles y la rama activa actual git branch |
Si deseas crear una nueva rama, ejecuta el siguiente comando:
|
1 2 3 4 |
# Crear una nueva rama git branch nombre_de_la_rama |
Tras crear una nueva rama, puedes observar que tu rama activa sigue siendo la anterior, para empezar el desarrollo en una nueva rama, ejecuta el siguiente comando:
|
1 2 3 4 |
# Desarrollar sobre una nueva rama git checkout nombre_de_la_rama |
Para crear una nueva rama y cambiar la rama activa, ejecuta el siguiente comando
|
1 2 3 4 |
# Crear una nueva rama y cambiar la rama activa git checkout -b nombre_de_la_rama |
Si necesitas cambiar el nombre de la rama actual, ejecuta el siguiente comando:
|
1 2 3 4 |
# Cambiar el nombre de la rama actual git branch -m nuevo_nombre_de_la_rama |
Puedes usar la opción -D para eliminar una rama disponible:
|
1 2 3 4 |
# Eliminar una rama git branch -D nombre_de_la_rama |
Actualiza tu Repositorio Local: Fusionar
Anteriormente hablamos conceptos básicos de la ramificación en Git, el siguiente paso lógico es fusionar una rama en su rama base, cuando hayas terminado de trabajar en solucionar un problema. Para fusionar una rama ejecuta los siguientes comandos:
|
1 2 3 4 5 |
# Fusionar una rama git checkout rama-base git merge nueva_rama |
Si bien parece un proceso fácil, la fusión de ramas, es el proceso que consume mas tiempo en Git, ya que puede generar conflictos durante el proceso de fusión.
Manejo de Conflictos
Por ejemplo, imagina que estas trabajando en un archivo que tiene una nueva rama, después de confirmar los cambios, solicitas a Git que combine la nueva rama con la rama base. Sin embargo, la misma parte de del mismo archivo en la rama base se ha actualizado desde que creaste la nueva rama. ¿ Cómo decide Git que cambios mantener y que cambios descartar ?
Lo que hace Git siempre es intentar no perder ningún dato en el proceso de fusión. Si los cambios en el mismo archivo se realizaron en diferentes partes del archivo, podría saltarse manteniendo ambos conjuntos de cambios. Sin embargo, si Git no puede decidir que cambios mantener, genera un conflicto.
Cuando se genera un conflicto, y al ejecutar el comando git status en tu repositorio, se muestra una lista de archivos que se modificaron en ambas ramas que se fusionaron.
Si abres cualquier archivo con un conflicto, notarás el siguiente conjunto de líneas:
|
1 2 3 4 5 6 7 8 9 |
<<<<<<<< HEAD ... ... ======== ... ... >>>>>>>> new_branch |
En el archivo anterior, por ejemplo, dentro de la parte <<<<<<<< HEAD se encontraría el código que está presente en la rama base. Las líneas de código entre ======== y >>>>>>>> new_branch contendría el código de la nueva rama.
Entonces el desarrollador que está fusionando el código tiene la responsabilidad de decidir que parte del código (o una combinación de ambas partes) debe incluirse en la fusión de las ramas.
Una vez editado, elimina los 3 conjuntos de líneas que aparecen en el archivo, guarda el archivo y confirma los cambios.
Ten Paciencia, lo que quiero es que entiendas todos los conceptos antes de unirte a un equipo Git y por eso continuaremos en una 2da parte con las demás técnicas.
Nota (s)
- En el siguiente capitulo terminaremos con las demás técnicas Git pendientes.
- No olvides que debemos usar la Tecnología para hacer cosas Buenas por el Mundo.
Síguenos en nuestras Redes Sociales para que no te pierdas nuestros próximos contenidos.