Para crear una rama a partir de otra en Git, sitúate primero en la rama de origen y ejecuta git switch -c <nueva-rama> o, con la sintaxis tradicional, git checkout -b <nueva-rama>. La nueva rama partirá del commit al que apunta actualmente la rama de origen.
Por ejemplo, para crear la rama feature a partir de main, puedes usar git switch main y después git switch -c feature, o crearla directamente indicando el punto de partida con git switch -c feature main. La rama se crea localmente y no aparece en el repositorio remoto hasta que la publiques con git push -u origin feature.
Qué es una rama en Git
En el día a día del trabajo con Git una de las cosas útiles que podemos hacer es trabajar con ramas. Las ramas son caminos que puede tomar el desarrollo de un software, algo que ocurre naturalmente para resolver problemas o crear nuevas funcionalidades.
En la práctica permiten que nuestro proyecto pueda tener diversos estados y que los desarrolladores sean capaces de pasar de uno a otro de una manera ágil. Las ramas facilitan varios flujos de trabajo colaborativos.
Por ejemplo imagina que estás trabajando en un proyecto y quieres implementar una nueva funcionalidad en la que sabes que quizás tengas que invertir varios días. Posiblemente sea algo experimental, que no sabes si llegarás a incorporar, o bien es algo que tienes claro que vas a querer completar, pero que, dado que te va a ocupar un tiempo indeterminado, es posible que en medio de tu trabajo tengas que tocar tu código, en el estado en el que lo tienes en producción.
Bajo el supuesto anterior lo que haces es crear una rama. Trabajas dentro de esa rama por un tiempo, pero de repente se te cuelga el servidor y te das cuenta que hay cosas en el proyecto que no están funcionando correctamente.
Los cambios de la rama no están completos, así que no los puedes subir. En ese instante, lo que las ramas Git te permiten es que, lanzando un sencillo comando, poner de nuevo el proyecto en el estado original que tenías, antes de empezar a hacer esos cambios que no has terminado.
Perfecto! solucionas la incidencia, sobre el proyecto original y luego puedes volver a la rama experimental para seguir trabajando en esa idea nueva.
Llegará un momento en el que, quizás, aquellos cambios experimentales los quieras subir a producción. Entonces harás un proceso de fusionado entre la rama experimental y la rama original, operación que se conoce como merge en Git.
Rama de origen y punto de partida
Una rama nueva parte de donde estás ahora, salvo que indiques un punto de partida distinto. Crear una rama inicia una nueva línea de commits desde donde estás - el nuevo puntero es instantáneo y gratis.
La rama main de tu repositorio es considerada como la rama principal, es la única rama presente por defecto. Cuando inicializamos un proyecto con Git automáticamente nos encontramos en una rama a la que se denomina "master".
En GitHub actualmente se está promoviendo la rama "main" como rama principal de los proyectos, de modo que, en vuestro caso quizás tengáis la rama "main" en vez de la rama "master" que mencionamos en este artículo. Es simplemente un cambio de nombre, pero realmente no va más allá.
Es decir, tengas "master" como nombre de la rama principal o "main", todo lo relatado en este artículo es exactamente igual. Esta rama es la principal de tu proyecto y a partir de la que podrás crear nuevas ramas cuando lo necesites.
Puedes ver la rama en la que te encuentras en cada instante con el comando:
git branch
Si has hecho algún commit en tu repositorio observarás que después de lanzar el comando "git branch" nos informa el nombre de la rama como "master". Si no has hecho un commit en tu proyecto observarás que no se ha creado todavía ninguna rama y que el comando branch no produce ninguna salida.
Es importante mencionar aquí que actualmente al escribir "git branch" se nos muestra un listado de ramas y se mantiene el terminal mostrando ese listado, como parado, sin la posibilidad de lanzar otros comandos.
Puede que no ocurra en tu caso y que el comando simplemente muestre las ramas y permita luego escribir otros comandos de sistema. En todo caso, si te muestra las ramas pero te bloquea el terminal, algo que hace Git para facilitar la lectura de las ramas en proyectos donde tengas muchas creadas, puedes salir de ese listado de ramas tocando la tecla "q".
Crear una rama a partir de la rama actual
Crear la rama sin cambiar a ella
El procedimiento para crear una nueva rama es bien simple. Usando el comando branch, seguido del nombre de la rama que queremos crear.
git branch experimental
Este comando en sí no produce ninguna salida, pero podrías ver las "branches" de un proyecto con el comando "git branch".
El comando git branch <nombre-rama> crea la rama sin cambiar a ella. Como puede ver, la rama no cambió, pero se creó una nueva rama.
Para ver una lista de todas las ramas disponibles, puede usar este comando:
git branch
La rama nueva se crea a partir del commit actual, pero tu rama activa continúa siendo la misma. Esta opción resulta útil cuando quieres preparar una rama para usarla más adelante o comprobar primero que el nombre y el punto de partida son correctos.
Crear la rama y cambiar a ella
La forma moderna de crear una rama y cambiar a ella en un solo paso es git switch -c <name>. El más antiguo git checkout -b <name> hace lo mismo y sigue funcionando en todas partes.
La opción -b es una marca muy útil con la que Git ejecuta git branch <new-branch> antes de hacer lo propio con git checkout <new-branch>.
Podemos crear una nueva rama y movernos a ella usando el comando git checkout con la opción -b y <nombre-rama>.
git checkout -b <branch-name>
El comando checkout tiene la posibilidad de permitirte crear una rama nueva y moverte a ella en un único paso. Para crear una nueva rama y situarte sobre ella tendrás que darle un nombre y usar el parámetro -b.
git checkout -b otrarama
Como salida obtendrás el mensaje Switched to a new branch 'otrarama'. Eso quiere decir que, además de crear la rama, nuestra cabecera está apuntando hacia esta nueva branch.
La alternativa moderna equivalente es:
git switch -c feature
Ambos crean la nueva rama a partir de tu commit actual y la comprueban de inmediato, así que puedes empezar a trabajar en ella enseguida.
Crear una rama a partir de otra rama concreta
Si quieres crear una rama a partir de otra rama concreta, añade el nombre de la rama de origen como último argumento:
git switch -c feature main
Este comando crea feature partiendo de main, aunque no estuvieras situado previamente en main.
También puedes crear una rama a partir de otra rama con la sintaxis tradicional:
git checkout -b <new-branch> <existing-branch>
De manera predeterminada, git checkout -b basará la rama new-branch en el HEAD actual. No obstante, git checkout puede combinarse con un parámetro opcional para ramas adicionales.
En el ejemplo anterior, se añade <existing-branch>, que basa new-branch en existing-branch y no en el HEAD actual.
Por ejemplo, para crear una rama llamada paginación desde main, puedes ejecutar:
git switch -c paginación main
La nueva rama comenzará exactamente en el commit al que apunta main. Después, Git cambiará automáticamente a paginación.
Crear una rama a partir de un commit específico
También puedes crear una rama partiendo de un commit específico:
git switch -c feature <hash>
Sin punto de partida, la rama se crea a partir de tu HEAD actual.
En términos de Git, HEAD hace referencia a la instantánea actual. De forma interna, el comando git checkout simplemente actualiza el HEAD para que apunte a la rama o la confirmación especificadas.
Git realiza un seguimiento del historial de operaciones de extracción en el registro de referencias. Puedes ejecutar git reflog para ver el historial.
Comprobar la rama activa
Antes de crear una rama a partir de otra, conviene comprobar cuál es la rama activa:
git branch
El comando git branch nos muestra el listado de ramas del proyecto y marca la rama activa con un asterisco. También puedes usar:
git status
El comando git status permite comprobar la rama actual y el estado de los archivos antes de cambiar de rama o crear una rama nueva.
Cambiar entre ramas
Para moverse entre ramas usamos el comando "git checkout" seguido del nombre de la rama que queremos que sea la activa.
git checkout experimental
La forma moderna y específica de cambiar de rama es:
git switch experimental
El comando git checkout te permite desplazarte entre las ramas creadas por git branch. Al extraer una rama, se actualizan los archivos en el directorio de trabajo para reflejar la versión almacenada en esa rama y se indica a Git que registre todas las confirmaciones nuevas en dicha rama.
Esta sencilla operación tiene mucha potencia, porque nos cambiará automáticamente todos los archivos de nuestro proyecto, los de todas las carpetas, para que tengan el contenido en el que se encuentren en la correspondiente rama.
De momento en nuestro ejemplo las dos ramas tenían exactamente el mismo contenido, pero ahora podríamos empezar a hacer cambios en el proyecto experimental y sus correspondientes commit y entonces los archivos tendrán códigos diferentes, de modo que puedas ver que al pasar de una rama a otra hay cambios en los archivos.
Si te dedicas a editar tus ficheros, crear nuevos archivos y demás en las distintas ramas entonces podrás observar que al moverte de una a otra con checkout el proyecto cambia automáticamente en tu editor, mostrando el estado actual en cada una de las ramas donde te estás situando.
Como estás entendiendo, el proyecto puede tener varios estados en un momento dado y tú podrás moverte de uno a otro con total libertad y sin tener que cambiar de carpeta ni nada parecido.
En ocasiones, el comando git checkout puede confundirse con git clone. La diferencia entre ambos comandos estriba en que el segundo recupera código de un repositorio remoto, mientras que el primero cambia entre versiones de código que ya se encuentran en el sistema local.
Estado de los cambios antes de cambiar de rama
Antes de poder saltar a otra rama, es importante revisar los cambios que todavía no estén confirmados.
Pero, antes de poder hacer eso, hemos de tomar en cuenta que si tenemos cambios aún no confirmados en el directorio de trabajo o en el área de preparación, Git no nos permitirá saltar a otra rama con la que podríamos tener conflictos.
Lo mejor es tener siempre un estado de trabajo limpio y despejado antes de saltar entre ramas.
Por ahora, como tenemos confirmados todos los cambios, podemos saltar a la rama master sin problemas:
git checkout master
Si tienes cambios sin confirmar y necesitas cambiar de contexto, puedes confirmar esos cambios o utilizar procedimientos como stash y corregir confirmaciones.
Git revierte el directorio de trabajo exactamente al estado en que estaba en la confirmación (commit) apuntada por la rama que activamos (checkout) en cada momento.
Git añade, quita y modifica archivos automáticamente para asegurar que tu copia de trabajo luce exactamente como lucía la rama en la última confirmación de cambios realizada sobre ella.
Ejemplo completo: crear una rama desde main
Imagina que trabajas en un sitio web y quieres crear una rama para una nueva función. Primero comprueba las ramas disponibles:
git branch
Después, sitúate en la rama principal:
git switch main
A continuación, crea la nueva rama y cambia a ella:
git switch -c paginación
La sintaxis tradicional equivalente es:
git checkout -b paginación
Como puede ver, creamos una nueva rama y el comando checkout hizo que nuestra rama cambiara automáticamente de "main" a "paginación".
Una vez dentro de la nueva rama, puedes editar archivos y crear confirmaciones:
git add .
git commit -m 'Añadida la paginación'
La rama paginación avanzará con sus propios commits sin modificar automáticamente la rama main.
Ejemplo completo: crear una rama para una incidencia urgente
Vamos a presentar un ejemplo simple de ramificar y de fusionar, con un flujo de trabajo que se podría presentar en la realidad.
Trabajas en un sitio web. Creas una rama para un nuevo tema sobre el que quieres trabajar. Realizas algo de trabajo en esa rama.
En este momento, recibes una llamada avisándote de un problema crítico que has de resolver. Vuelves a la rama de producción original.
Creas una nueva rama para el problema crítico y lo resuelves trabajando en ella. Tras las pertinentes pruebas, fusionas (merge) esa rama y la envías (push) a la rama de producción.
Vuelves a la rama del tema en que andabas antes de la llamada y continúas tu trabajo.
Crear la rama de la funcionalidad
Imagina que estas trabajando en un proyecto y tienes un par de confirmaciones (commit) ya realizadas.
Decides trabajar en el problema #53, según el sistema que tu compañía utiliza para llevar el seguimiento de los problemas. Para crear una nueva rama y saltar a ella, en un solo paso, puedes utilizar el comando git checkout con la opción -b:
git checkout -b iss53
Esto es un atajo para:
git branch iss53
git checkout iss53
Trabajas en el sitio web y haces algunas confirmaciones de cambios (commits). Con ello avanzas la rama iss53, que es la que tienes activada (checked out) en este momento (es decir, a la que apunta HEAD).
git commit -a -m 'added a new footer [issue 53]'
Crear una rama temporal para la corrección
Entonces, recibes una llamada avisándote de otro problema urgente en el sitio web y debes resolverlo inmediatamente.
Al usar Git, no necesitas mezclar el nuevo problema con los cambios que ya habías realizado sobre el problema #53; ni tampoco perder tiempo revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción.
Basta con saltar de nuevo a la rama master y continuar trabajando a partir de allí.
git checkout master
Tras esto, tendrás el directorio de trabajo exactamente igual a como estaba antes de comenzar a trabajar sobre el problema #53 y podrás concentrarte en el nuevo problema urgente.
A continuación, es momento de resolver el problema urgente. Vamos a crear una nueva rama hotfix, sobre la que trabajar hasta resolverlo:
git checkout -b hotfix
Después de corregir el archivo, puedes guardar los cambios:
git commit -a -m 'fixed the broken email address'
Puedes realizar las pruebas oportunas, asegurarte de que la solución es correcta, e incorporar los cambios a la rama master para ponerlos en producción.
Fusionar la rama creada con la rama de origen
A medida que crees ramas y cambies el estado de las carpetas o archivos tu proyecto empezará a divergir de una rama a otra.
Llegará el momento en el que te interese fusionar ramas para poder incorporar el trabajo realizado a la rama master.
El proceso de fusionado se conoce como "merge" y puede llegar a ser muy simple o más complejo si se encuentran cambios que Git no pueda procesar de manera automática.
Para hacer un merge nos situamos en una rama, en este caso la "master", y decimos con qué otra rama se debe fusionar el código.
El siguiente comando, lanzado desde la rama "master", permite fusionarla con la rama "experimental".
git merge experimental
Para fusionar la rama feature con main, debes situarte en main y ejecutar:
git switch main
git merge feature
Git para procesar los merge usa un antecesor común y comprueba los cambios que se han introducido al proyecto desde entonces, combinando el código de ambas ramas.
Avance rápido
Si la rama principal no tiene commits nuevos desde que se creó la rama de trabajo, Git puede realizar un avance rápido.
Notarás la frase “Fast forward” (“Avance rápido”, en inglés) que aparece en la salida del comando.
Git ha movido el apuntador hacia adelante, ya que la confirmación apuntada en la rama donde has fusionado estaba directamente arriba respecto a la confirmación actual.
Dicho de otro modo: cuando intentas fusionar una confirmación con otra confirmación accesible siguiendo directamente el historial de la primera; Git simplifica las cosas avanzando el puntero, ya que no hay ningún otro trabajo divergente a fusionar.
Esto es lo que se denomina “avance rápido” (“fast forward”). Ahora, los cambios realizados están ya en la instantánea (snapshot) de la confirmación (commit) apuntada por la rama master.
Fusión a tres bandas
En una fusión a tres bandas, Git utiliza las dos instantáneas apuntadas por el extremo de cada una de las ramas y por el ancestro común a ambas.
En lugar de simplemente avanzar el apuntador de la rama, Git crea una nueva instantánea (snapshot) resultante de la fusión a tres bandas; y crea automáticamente una nueva confirmación de cambios (commit) que apunta a ella.
Nos referimos a este proceso como "fusión confirmada" y su particularidad es que tiene más de un padre.
Vale la pena destacar el hecho de que es el propio Git quien determina automáticamente el mejor ancestro común para realizar la fusión.
Actualizar una rama a partir de otra
Crear una rama a partir de otra y actualizarla posteriormente son operaciones diferentes. Para traer a tu rama actual los cambios de otra rama, sitúate en la rama que quieres actualizar y ejecuta git merge con la rama de origen.
Por ejemplo, la rama experimental está tardando varios días o semanas en completarse y mientras tanto han agregado nuevas features que quieras que esté disponibles también en la rama experimental.
Entonces seguramente querrás traerte los cambios de la rama master. Para ello, estando en la rama experimental, puedes lanzar el siguiente comando.
git merge master -m 'Un mensaje del merge de master en el branch experimental'
Ya lo tienes! ahora tu rama está actualizada con todos los cambios en master. Puedes seguir desarrollando tu rama experimental sabiendo que tienes el proyecto actualizado.
También puedes esperar hasta que decidas fusionar (merge) la rama iss53 a la rama master.
Resolver conflictos durante la fusión
En algunas ocasiones, los procesos de fusión no suelen ser fluidos. Si hay modificaciones dispares en una misma porción de un mismo archivo en las dos ramas distintas que pretendes fusionar, Git no será capaz de fusionarlas directamente.
Git no crea automáticamente una nueva fusión confirmada (merge commit), sino que hace una pausa en el proceso, esperando a que tú resuelvas el conflicto.
Para ver qué archivos permanecen sin fusionar en un determinado momento conflictivo de una fusión, puedes usar el comando git status.
git status
Todo aquello que sea conflictivo y no se haya podido resolver, se marca como "sin fusionar" (unmerged).
Git añade a los archivos conflictivos unos marcadores especiales de resolución de conflictos que te guiarán cuando abras manualmente los archivos implicados y los edites para corregirlos.
El archivo conflictivo contendrá algo como:
<<<<<<< HEAD:index.html
<div id="footer">contact : </div>
=======
<div id="footer"> please contact us at </div>
>>>>>>> iss53:index.html
Donde nos dice que la versión en HEAD (la rama master, la que habías activado antes de lanzar el comando de fusión) contiene lo indicado en la parte superior del bloque (todo lo que está encima de =======) y que la versión en iss53 contiene el resto, lo indicado en la parte inferior del bloque.
Para resolver el conflicto, has de elegir manualmente el contenido de uno o de otro lado.
Esta corrección contiene un poco de ambas partes y se han eliminado completamente las líneas <<<<<<<, ======= y >>>>>>>.
Tras resolver todos los bloques conflictivos, has de lanzar comandos git add para marcar cada archivo modificado.
Marcar archivos como preparados (staged) indica a Git que sus conflictos han sido resueltos.
git add index.html
Si en lugar de resolver directamente prefieres utilizar una herramienta gráfica, puedes usar el comando git mergetool, el cual arrancará la correspondiente herramienta de visualización y te permitirá ir resolviendo conflictos con ella:
git mergetool
En cualquier momento, puedes lanzar el comando git status para ver si ya has resuelto todos los conflictos.
Si todo ha ido correctamente, y ves que todos los archivos conflictivos están marcados como preparados, puedes lanzar el comando git commit para terminar de confirmar la fusión.
git commit
Puedes modificar este mensaje añadiendo detalles sobre cómo has resuelto la fusión, si lo consideras útil para que otros entiendan esta fusión en un futuro.
Publicar la rama en un repositorio remoto
Las ramas de un repositorio local pueden ser distintas de las ramas de un repositorio remoto.
Cuando creas una rama en tu repositorio local, la rama la tendrás simplemente en tu proyecto local y no se subirá al repositorio remoto hasta que no lo especifiques.
Por mucho que hagas la operativa descrita para crear ramas en tu ordenador, y las puedas ver en tu repositorio local con git branch, las ramas no se publicarán en Github o cualquier otro hosting de repositorios remoto.
Para que esto ocurra tienes que realizar específicamente la acción de subir una rama determinada.
La operativa de publicar una rama en remoto la haces mediante el comando push, indicando la opción "-u" y el nombre de la rama que deseas subir.
git push -u origin feature
Así estamos haciendo un push, empujando hacia origin (que es el nombre que se suele dar al repositorio remoto), la rama con nombre "feature".
El -u establece el upstream para que futuros git push y git pull en esa rama no necesiten argumentos.
La rama no existe en el remoto hasta que la subes.
Crear una rama a partir de una rama remota
Las ramas de un repositorio local pueden ser distintas de las ramas de un repositorio remoto. Por ejemplo, cuando clonas un repositorio de GitHub generalmente estás clonando únicamente la rama master y no todas las ramas que se hayan creado a lo largo del tiempo.
Al colaborar con un equipo, se utilizan con frecuencia repositorios remotos. Estos repositorios pueden alojarse y compartirse, o bien pueden ser una copia local de otro compañero.
Cada repositorio remoto contendrá su propio conjunto de ramas.
Para actualizar las referencias del repositorio remoto puedes ejecutar:
git fetch
Lanzado ese comando hemos podido descargar la rama git de remoto.
Para crear una rama local a partir de una rama remota puedes ejecutar:
git switch -c feature origin/feature
En las versiones anteriores de Git, se debe crear una nueva rama basada en la remote.
git checkout -b <remotebranch> origin/<remotebranch>
En las versiones modernas de Git, puedes cambiar a la rama remota como si fuera una rama local.
git checkout <remotebranch>
Además, puedes cambiar a una nueva rama local y restablecerla en la última confirmación de las ramas remotas.
git checkout -b <branchname>
git reset --hard origin/<branchname>
En principio esas ramas en remoto creadas por otros usuarios no están disponibles para nosotros en local, pero las podemos descargar.
Ahora podemos acceder a ella con los comandos que ya conoces.
git checkout mi_rama_remota_descargada
Eliminar una rama
En ocasiones puede ser necesario eliminar una rama del repositorio, por ejemplo porque nos hayamos equivocado en el nombre al crearla.
El borrado de una rama puede ser diferente, dependiendo de si hemos subido ya esa rama a remoto o si todavía solamente está en local.
Borrar una rama local
Esto lo conseguimos con el comando git branch, solamente que ahora usamos la opción "-d" para indicar que esa rama queremos borrarla.
git branch -d rama_a_borrar
La opción -d es más segura, ya que no permite borrado de ramas en situaciones donde se pueda perder código.
Sin embargo, puede que esta acción no nos funcione porque hayamos hecho cambios que no se hayan salvado en el repositorio remoto, o no se hayan fusionado con otras ramas.
En el caso que queramos forzar el borrado de la rama, para eliminarla independientemente de si se ha hecho el push o el merge, tendrás que usar la opción "-D".
git branch -D rama_a_borrar
Debes prestar especial atención a esta opción "-D", ya que al eliminar de este modo pueden haber cambios que ya no se puedan recuperar.
Borrar una rama remota
Si la rama que queremos eliminar está en el repositorio remoto, la operativa es un poco diferente.
Tenemos que hacer un push, indicando la opción --delete, seguida de la rama que se desea borrar.
git push origin --delete rama_a_borrar
HEAD desasociado
Cuando apunta a una rama, Git no objeta nada, pero cuando extraes una confirmación, pasa al estado detached HEAD.
Se trata de una advertencia que indica que todo lo que haces está "desconectado" del resto del desarrollo de tu proyecto.
Si empezaras a desarrollar una función mientras el estado fuera detached HEAD, no habría ninguna rama que te permitiera volver a ella.
Cuando inevitablemente extrajeras otra rama (por ejemplo, para fusionar tu función), no habría forma de hacer referencia a la función.
La cuestión es que el desarrollo siempre debe llevarse a cabo en una rama, nunca en un HEAD desasociado.
De este modo, te aseguras de tener siempre una referencia para las nuevas confirmaciones. Sin embargo, si solo estás mirando una confirmación anterior, da igual que te encuentres en el estado detached HEAD o no.
Comandos principales
| Objetivo | Comando |
|---|---|
| Crear una rama y cambiar a ella | git switch -c feature |
| Crear y cambiar con la sintaxis tradicional | git checkout -b feature |
| Crear una rama sin cambiar a ella | git branch feature |
| Crear feature partiendo de main | git switch -c feature main |
| Crear una rama partiendo de un commit | git switch -c feature <hash> |
| Cambiar a una rama existente | git switch feature |
| Fusionar una rama en la actual | git merge feature |
| Subir una rama nueva y establecer el upstream | git push -u origin feature |
| Ramificar desde una rama remota | git switch -c feature origin/feature |
| Eliminar una rama local | git branch -d feature |
| Eliminar una rama remota | git push origin --delete feature |
Preguntas frecuentes
¿Cómo creo una rama y cambio a ella en un solo comando?
Ejecuta git switch -c <name> (Git moderno) o el equivalente git checkout -b <name>. Ambos crean la nueva rama a partir de tu commit actual y la comprueban de inmediato, así que puedes empezar a trabajar en ella enseguida.
¿Cuál es la diferencia entre git switch -c y git checkout -b?
Hacen lo mismo: crear una rama y cambiar a ella. git switch es el comando más nuevo y enfocado, introducido para separar el cambio de rama de los muchos otros usos de git checkout.
git checkout -b es más antiguo pero sigue plenamente soportado; usa el que prefiera tu equipo.
¿Cómo creo una rama a partir de otra rama o de un commit específico?
Añade un punto de partida como último argumento: git switch -c feature main ramifica desde main, y git switch -c feature <hash> ramifica desde un commit específico.
Sin punto de partida, la rama se crea a partir de tu HEAD actual.
¿Cómo subo una rama nueva al remoto?
Después de crearla localmente, ejecuta git push -u origin <name>. El -u establece el upstream para que futuros git push y git pull en esa rama no necesiten argumentos.
La rama no existe en el remoto hasta que la subes.
