Master, main y otros nombres de rama

Arrancamos con un tema fresco. Hace ya un tiempo que se empezó a recomendar no usar "master" como nombre de la rama principal, por lo que hoy día Git tiene ajustes para cambiar el nombre de la rama, y también hay que estar pendiente de lo que se clona.

Git ha experimentado cambios importantes en los últimos años para hacer su uso diario más sencillo y adaptado a las necesidades actuales de los desarrolladores. Uno de esos cambios tiene que ver con el nombre que se asigna por defecto a la rama principal de un repositorio. Tradicionalmente, esa rama se llamaba master, pero hoy en día ya no es obligatorio ni recomendable mantener ese nombre.

Cuando creamos un repositorio con git init, lo habitual era que se generara una rama principal llamada master. Sin embargo, Git ha evolucionado y ahora nos avisa de que ese nombre podría cambiar en el futuro. De hecho, muchas plataformas como GitHub o GitLab ya utilizan main como nombre por defecto para la rama principal. Esto responde a un deseo de desligarse de ciertas connotaciones históricas que tiene la palabra master, que provienen de herramientas anteriores como Bitkeeper, en las que el término tenía un significado diferente y más cargado.

Además, no solo main es una opción válida. Algunos desarrolladores prefieren otros nombres como trunk o development. Por ejemplo, nosotros solemos usar trunk como nombre para la rama principal, en homenaje a sistemas de control de versiones anteriores como SVN, que utilizaban ese término. Lo importante es que Git nos permite personalizar este nombre para que se adapte a nuestro flujo de trabajo y preferencias.

Para configurar el nombre por defecto de la rama principal en nuestro entorno local, podemos usar el comando:

git config --global init.defaultBranch trunk

Con esto, cada vez que creemos un nuevo repositorio con git init, la rama principal se llamará trunk en lugar de master. Si ya hemos creado un repositorio y queremos cambiar el nombre de la rama principal, podemos hacerlo con:

git branch -m master trunk

o el nombre que queramos darle.

Este cambio de nombres puede generar cierta confusión cuando trabajamos con repositorios remotos. Por ejemplo, si en GitHub la rama principal se llama main y en nuestro repositorio local la llamamos master o trunk, al sincronizar puede que Git no encuentre la rama correcta y nos dé errores. Para evitar esto, es importante asegurarnos de que el nombre de la rama principal coincida entre el repositorio remoto y el local, o configurar correctamente el seguimiento de ramas.

En plataformas como GitHub o GitLab, podemos cambiar el nombre de la rama principal desde la interfaz web, eligiendo cuál será la rama por defecto. Esto facilita la integración con nuestro entorno local y evita conflictos.

En definitiva, el cambio en el nombre de la rama principal en Git refleja una evolución hacia prácticas más inclusivas y flexibles, además de facilitar la personalización y evitar confusiones al trabajar con repositorios remotos que pueden tener nombres distintos para la rama principal. Adaptarnos a esta realidad nos ayudará a tener un flujo de trabajo más claro y moderno.

Lista de reproducción
  1. 1
    ¿Qué es Git?
    4 minutos
  2. 2
    Cómo instalar Git
    9 minutos
  3. 3
    Creando tu primer commit
    9 minutos
  4. 4
    Qué es el staging area
    10 minutos
  5. 5
    Cómo deshacer modificaciones de archivos
    7 minutos
  6. 6
    Cómo deshacer un commit con reset
    7 minutos
  7. 7
    Cómo revertir un commit con revert
    7 minutos
  8. 8
    Introducción a las ramas
    6 minutos
  9. 9
    Cómo crear y modificar ramas
    6 minutos
  10. 10
    Commits bajo el workflow Feature Branch
    6 minutos
  11. 11
    Cómo fusionar ramas con merge
    6 minutos
  12. 12
    Fusiones conflictivas
    9 minutos
  13. 13
    Cómo construir alias
    7 minutos
  14. 14
    Más sobre conflictos
    9 minutos
  15. 15
    Etiquetas
    7 minutos
  16. 16
    Tags anotados
    9 minutos
  17. 17
    git stash: esconder cambios
    6 minutos
  18. 18
    Introducción a remotos
    5 minutos
  19. 19
    Pusheando a un remoto
    6 minutos
  20. 20
    Clonando y haciendo pull
    6 minutos
  21. 21
    Fetch y pull rebases
    8 minutos
  22. 22
    Rebase
    7 minutos
  23. 23
    Rebase interactivo
    6 minutos
  24. 24
    Master, main y otros nombres de rama
    9 minutos
  25. 25
    git switch
    9 minutos
  26. 26
    git-restore
    10 minutos
  27. 27
    git-grep
    11 minutos
  28. 28
    Gitignore
    11 minutos
  29. 29
    El flag --patch
    9 minutos
  30. 30
    git-apply y parches en bruto (advanced)
    9 minutos
  31. 31
    Merge octopus (advanced)
    9 minutos
  32. 32
    Conventional commits
    12 minutos
  33. 33
    Merge and squash (GitLab / GitHub...)
    6 minutos
  34. 34
    git merge --squash
    7 minutos
  35. 35
    git-bisect
    8 minutos
  36. 36
    git-blame
    6 minutos
  37. 37
    git-reflog
    10 minutos
  38. 38
    Git para la Bash
    11 minutos
  39. 39
    Submódulos (parte 1)
    7 minutos
  40. 40
    Submódulos (parte 2)
    10 minutos
  41. 41
    Otros clientes Git (último episodio)
    9 minutos