Git crear rama desde master
¿No sería genial poder mantener tu código actualizado sin afectar a la rama maestra? Pues bien, con la creación de ramas en Git, ¡podemos hacerlo! En términos sencillos, la creación de ramas en Git es un proceso de creación y eliminación de ramas, así como de listado y cambio de sus nombres. Con esta poderosa herramienta, podemos mantener el control de versiones de tu código de forma fácil y eficiente. Entonces, ¿por qué esperar? Empecemos a entender cómo usar la ramificación de Git y cómo crear una rama de Git hoy mismo.
Cuando creas un nuevo repositorio Git, automáticamente obtienes una rama maestra que apunta al primer commit realizado en ese repo. Cada vez que haces un commit, el puntero de la rama maestra se mueve hacia adelante automáticamente. Sólo puedes tener una rama maestra en un repositorio determinado.
La rama maestra es la rama más importante de su proyecto. Cada cambio realizado en tu código base debe ser fusionado en esta rama. Esto es lo que llamamos la «versión oficial de trabajo» de su proyecto.
Antes de seguir adelante y crear ramas en nuestro sistema local, es importante que aprendamos a ver las ramas existentes tanto localmente como en el repositorio remoto. De esta manera, podemos estar al día con el proyecto en su conjunto mientras trabajamos en nuestras tareas individuales.
Git crea una nueva rama desde la remota
La primera confirmación en un nuevo repositorio de Git es el inicio de la rama principal. A medida que trabajas en la rama principal, haces confirmaciones para registrar tu trabajo en esa rama. La ramificación en Git se produce cuando creas una nueva línea de desarrollo que difiere de una rama anterior. Puedes elegir crear una nueva rama para desarrollar y probar una nueva característica antes de añadirla a tu rama principal. El flujo de trabajo recomendado en Git es utilizar una nueva rama para cada función o corrección de errores. Cuando cambias de rama, Git cambia casi instantáneamente la versión de los archivos de tu repositorio para que coincida con la rama que has seleccionado. Tus confirmaciones siempre se guardan en la rama actual, y están aisladas de las confirmaciones en otras ramas.
Los nombres de las ramas no pueden contener caracteres de control ASCII, como espacios, tildes y dos puntos. Es una práctica común utilizar caracteres en minúsculas y separar las palabras con un guión. Se pueden utilizar barras inclinadas para agrupar ramas. La longitud del nombre de la rama no debe superar los 250 caracteres ASCII. Para evitar la ambigüedad entre los nombres de las ramas y los hashes de las confirmaciones, no utilice nombres de ramas que consten de 40 caracteres hexadecimales. Para más información sobre la denominación de las ramas, consulta git-check-ref-format y Git cross-platform compatibility.
Git eliminar rama
Este documento es una revisión en profundidad del comando git branch y una discusión del modelo general de ramificación de Git. La ramificación es una característica disponible en la mayoría de los sistemas de control de versiones modernos. La ramificación en otros sistemas de control de versiones puede ser una operación costosa tanto en tiempo como en espacio de disco. En Git, las ramas forman parte de tu proceso de desarrollo diario. Las ramas de Git son efectivamente un puntero a una instantánea de tus cambios. Cuando quieras añadir una nueva función o corregir un error -no importa lo grande o lo pequeño que sea- creas una nueva rama para encapsular tus cambios. Esto hace más difícil que el código inestable se fusione con la base de código principal, y te da la oportunidad de limpiar el historial de tu futuro antes de fusionarlo con la rama principal.
El diagrama anterior visualiza un repositorio con dos líneas de desarrollo aisladas, una para una pequeña característica, y otra para una característica de mayor duración. Al desarrollarlas en ramas, no sólo es posible trabajar en ambas en paralelo, sino que también mantiene la rama principal libre de código dudoso.
Git crear rama local
Como se ha señalado en los comentarios y en la respuesta de Jackub, siempre que tu rama sea más joven que el número de días establecido en la configuración gc.reflogexpire (el valor por defecto es de 90 días), entonces puedes utilizar tu reflog para averiguar cuándo se creó por primera vez una referencia a una rama.
Ten en cuenta que git reflog puede tomar la mayoría de las banderas de registro de git. Además, ten en cuenta que los selectores de estilo HEAD@{0} son efectivamente nociones de tiempo y, de hecho, se manejan (de una manera pirateada) como cadenas de fecha. Esto significa que puede utilizar la bandera –date=local y obtener una salida como ésta:
Una última nota: la bandera –all (que en realidad es una bandera git-log entendida por git-reflog) mostrará los reflogs de todas las refs conocidas en refs/ (en lugar de simplemente, HEAD) lo que le mostrará claramente los eventos de las ramas:
verás lo que parece la «historia de tu rama», pero en realidad es una lista de commits accesibles desde ‘branch’ que no son accesibles desde master. Esto le da la información que desea, pero si y sólo si usted nunca ha fusionado ‘rama’ de nuevo a maestro, y nunca ha fusionado maestro en ‘rama’ desde que lo creó. Si usted ha fusionado, entonces esta historia de las diferencias se derrumbará.
