Original article: Git Checkout Remote Branch Tutorial
Git es una herramienta de control de versiones que le permite mantener y ver diferentes versiones de su aplicación. Cuando una nueva actualización rompe su aplicación, Git le permite revertir esos cambios a la versión anterior.
Además del control de versiones, Git le permite trabajar en múltiples entornos al mismo tiempo. Múltiples entornos en este contexto significa ramas.
¿Por qué necesitas ramas?
Cuando trabajes con git, tendrás un entorno maestro (también llamado principal) (rama). Esta rama en particular contiene el código fuente que se implementa cuando su aplicación está lista para la producción.
Cuando desees actualizar su aplicación, también puedes agregar más cambios (commits) a esta rama. Para cambios menores, esto puede no ser un gran problema, pero para cambios grandes, hacer esto no es lo ideal. Y es por eso que existen otras ramas.
Para crear y usar una nueva rama, usa el siguiente comando en tu terminal en el directorio del proyecto:
# crear una nueva rama
git branch rama-nombre
# cambiar el ambiente a la nueva rama
git checkout rama-nombre
En esta nueva rama, puede crear los nuevos cambios. Luego, cuando hayas terminado, puedes combinarlos con la rama maestra.
Otro beneficio de las ramas es que permiten que varios desarrolladores trabajen en el mismo proyecto simultáneamente. Si tienes varios desarrolladores trabajando en la misma rama maestra, puede ser desastroso. Tiene demasiados cambios entre el código de cada desarrollador, y esto generalmente termina en conflictos de combinación.
Con Git, puede saltar a otra rama (otro entorno) y realizar cambios allí, mientras se trabaja en otras ramas.
¿Qué significa rama remota de Git Checkout?
Cuando comienzas un proyecto con Git, obtiene dos entornos: la rama maestra local (que existe en su computadora) y la rama maestra remota (que existe en una plataforma compatible con Git como GitHub).
Puedes enviar cambios desde la rama principal local a la rama principal remota y también extraer cambios de la rama remota.
Cuando creas una rama localmente, solo existe localmente hasta que se envía a GitHub, donde se convierte en la rama remota. Esto se muestra en el siguiente ejemplo:
# crear una nueva rama
git branch nueva-rama
# cambiar el ambiente a la nueva rama
git checkout nueva-rama
# crear un cambio
touch nuevo-archivo.js
# cometer el cambio
git add .
git commit -m "añadir nuevo archivo"
# empujar a una nueva rama
git push --set-upstream origin nueva-rama
Del ejemplo anterior, origin nueva-rama se convierte en la rama remota. Como habrás notado, creamos una nueva rama y confirmamos un cambio en ella antes de pasar a la nueva rama remota.
Pero, ¿qué pasaría si la rama remota ya existiera y quisiéramos llevar la rama y todos sus cambios a nuestro entorno local?
Ahí es donde hacemos una "Rama Remota de Git Checkout".
Cómo hacer Git Checkout en una rama remota
Digamos que hay una rama remota creada por otro desarrollador y desea extraer esa rama. Así es como lo haces:
1. Recuperar todas las ramas remotas
git fetch origin
Esto recupera todas las ramas remotas del repositorio. origin es el nombre remoto al que se dirige. Entonces, si tenía un nombre remoto upstream, puedes llamar a git fetch upstream.
2. Enumera las ramas disponibles para checkout
Para ver las ramas disponibles para checkout, ejecute lo siguiente:
git branch -a
El resultado de este comando es la lista de ramas disponibles para checkout. Para las ramas remotas, las encontrará con el prefijo remotes/origin.
3. Obtener cambios de una rama remota
Tenga en cuenta que no puedes hacer cambios directamente en una rama remota. Por lo tanto, necesitas una copia de esa rama. Digamos que deseas copiar fix-failing-tests de la rama remota, así es como lo harías:
git checkout -b fix-failing-tests origin/fix-failing-tests
Lo que esto hace es:
- crea una nueva rama llamada
fix-failing-tests checkoutesa rama- extrae los cambios desde el origin/fix-failing-tests a esa rama
Y ahora tienes una copia de esa rama remota. Además, puedes enviar confirmaciones a esa rama remota. Por ejemplo, puedes empujar un nuevo compromiso así:
touch nuevo-archivo.js
git add .
git commit -m "añadir nuevo archivo"
git push
Esto empujará los cambios comprometidos a origin/fix-failing-tests. Si te diste cuenta, no tuvimos que especificar dónde estábamos enviando los cambios (como git push origin fix-failing-tests). Eso es porque git configura automáticamente la rama local para rastrear la rama remota.
Conclusión
La ramificación de Git facilita mucho la colaboración durante el desarrollo de aplicaciones.
Con las ramas, diferentes desarrolladores pueden trabajar fácilmente en diferentes partes de la aplicación simultáneamente.
Con la rama remota de Checkout, la colaboración se vuelve incluso más fluida, ya que los desarrolladores también pueden copiar ramas remotas localmente en sus sistemas, realizar cambios y enviarlos a las ramas remotas.