Skip to main content

Git checkout de una rama remota: cómo funciona y cuándo usarlo

Escrito por
blog feature snyk container custom base recommendations

15 de diciembre de 2020

0 minutos de lectura

Git es una herramienta fantástica que muchos desarrolladores usan para el control de versiones de sus proyectos. Aunque existen muchos otros sistemas de control de versiones —como Subversion (SVN) y Concurrent Versioning System (CVS)—, Git es, por mucho, el más utilizado. Una buena razón es su enfoque en el desarrollo distribuido y la facilidad para usar ramas. Veamos las ramas y qué significa realmente git checkout remote branch.

¿Qué es una rama?

Una rama es una forma sencilla de desviarse del flujo principal de desarrollo. Se suele usar para desarrollar una nueva funcionalidad o corregir un error en una rama. De esta manera, encapsulas los cambios y mantienes limpia tu rama main o master. Las ramas en Git son muy útiles, ya que son fáciles y relativamente económicas de crear. A diferencia de otros sistemas de control de versiones, en Git una rama no es una copia de tu código, sino simplemente un puntero al nodo original del que se creó.

Diagrama de una rama Main verde con cuatro confirmaciones y una rama Branch azul que se desvía desde su primera confirmación

¿Cómo cambio a una rama?

Si ya tienes una rama en tu máquina local, puedes cambiar a ella con el comando git checkout <branch name>.

Por ejemplo, si quieres crear una nueva rama llamada “dev” a partir de tu rama principal, usa git branch dev: esto solo crea la rama. Si quieres trabajar en ella y hacer commits, debes cambiar a esta rama como antes, usando git checkout dev.

Nota: cuando cambias a una rama en tu máquina local, todos los commits se harán en la nueva rama y no en la principal. Sabiendo esto, también puedes crear una rama a partir de otra rama de forma recursiva. Puede sonar extraño, pero imagina que estás desarrollando una nueva funcionalidad en una nueva rama y quieres experimentar un poco. Tiene mucho sentido hacerlo en una rama de otro nivel que se origine en la rama de tu funcionalidad.

¿Cómo cambio a una rama remota?

Una rama remota es la mejor manera de compartir tu trabajo de desarrollo con otras personas de tu equipo. Cabe mencionar que git checkout remote branch no es un comando que exista realmente. Si quieres cambiar a una rama remota que alguien publicó, primero debes usar git fetch. Este comando descarga las referencias de tu repositorio remoto a tu máquina local, incluida la referencia a la rama remota. Ahora solo tienes que usar git checkout <remote branch name>.

¿Cómo creo una rama local a partir de una rama remota?

Después de hacer un fetch, puedes cambiar a la rama remota como se mencionó antes. Esto significa que hay una copia local de la rama disponible en tu máquina. Si quieres cambiar a una rama remota y darle otro nombre en tu máquina local, puedes ejecutar:

git checkout -b myLocalName origin/remoteName

Tu rama local, myLocalName, quedará conectada a la rama remota remoteName. Ten en cuenta que origin es la referencia estándar al repositorio remoto original desde el que se clonó mi proyecto. Esto puede variar, por ejemplo, cuando trabajas con varios repositorios remotos.

¿Cómo analizo una rama local en busca de vulnerabilidades de seguridad?

Cada vez que cambies a una rama remota en tu máquina local, puedes analizarla localmente con Snyk CLI. Después de registrarte para obtener una cuenta gratuita e instalar la herramienta CLI, ve al directorio raíz de la rama y usa los siguientes comandos

  • snyk test para revisar dependencias de código abierto

  • snyk code test para analizar estáticamente tu código fuente en busca de vulnerabilidades

  • snyk container test para analizar tus contenedores en busca de problemas de seguridad

  • snyk iac test para asegurarte de que tu infraestructura como código no tenga vulnerabilidades

Consulta nuestra práctica hoja de referencia y la documentación para obtener más información.

¿Cómo convierto mi rama local en una rama remota?

Si estás en una rama local myNewFeature y quieres compartirla de forma remota, debes configurar la rama upstream para convertirla en una rama remota.

Cuando quiero subir mis cambios, primero debo usar -u o --set-upstream, así:

git push -u origin myNewFeature

Ahora la rama local también tiene una contraparte remota. La próxima vez que quiera subir cambios, puedo usar simplemente git push sin parámetros.

¿Cómo puedo mantener mi rama predeterminada libre de vulnerabilidades de seguridad?

Snyk ofrece integraciones nativas para todos tus proyectos en GitHub, Bitbucket, GitLab y Azure Repos. Al conectar tu repositorio, puedes usar herramientas como Snyk Open Source, Snyk Code, Snyk IaC y Snyk Container directamente en tu rama predeterminada. La integración con Git te ofrece pull request de corrección automáticos y analiza los PR entrantes antes de que los combines, para que puedas integrar la seguridad fácilmente en tu repositorio y evitar publicar código vulnerable.

Comienza con Capture the Flag

Aprende a resolver desafíos de Capture the Flag con nuestro taller virtual 101 a pedido.

Leer más

Blog

Los modelos de frontera encontraron las vulnerabilidades. Solo el atacante encontró las cadenas.

El análisis estático encontró las fallas, pero solo las pruebas de ataque en vivo demostraron cómo podían encadenarse para provocar brechas. Una comparación de Evo COS, Claude Security y Claude Code Security.

feature insights context
Blog

Los ataques autónomos ya están aquí. La defensa debe estar a su altura.

Los atacantes autónomos están reduciendo el tiempo disponible para defenderse. Descubre cómo el descubrimiento, la corrección, la validación y la prevención continuos pueden ayudar a los equipos de seguridad a seguirles el ritmo.

Blog

Por qué los agentes de programación con IA siguen generando fallas de control de acceso

Los agentes de programación con IA pueden generar lógica de autorización que compila y supera la revisión, pero expone los datos de un inquilino a otro. Descubre por qué es difícil detectar el control de acceso roto y cómo prevenirlo.