¿Cómo puedo crear un repositorio de Git con el nombre de rama predeterminado que no sea " master
"?
Usaría Git 2.28 (tercer trimestre de 2020): el nombre de la rama principal en los repositorios existentes, y el nombre predeterminado utilizado para la primera rama en los repositorios recién creados, se hace configurable, de modo que eventualmente podamos dejar de usar el código 'hardcode' master
'.
Y recordatorio de agosto de 2020 de GitHub :
El 1 de octubre de 2020, si no ha cambiado la rama predeterminada para nuevos repositorios para su usuario, organización o empresa, cambiará automáticamente de master
amain
.
Puede optar por no participar en este cambio en cualquier momento:
- Para los usuarios, en la página https://github.com/settings/repositories
- Para propietarios de organizaciones, en la
https://github.com/organizations/YOUR-ORGANIZATION/settings/repository-defaults
página
- Para administradores de empresas, en la
https://github.com/enterprises/YOUR-ENTERPRISE/settings/member_privileges
página
Este cambio es uno de los muchos cambios que GitHub está haciendo para respaldar proyectos y mantenedores que desean cambiar el nombre de su rama predeterminada.
Para obtener más información sobre los cambios que estamos realizando, consulte github / renaming .
Pero volvamos al propio Git: (2.28, tercer trimestre de 2020) Ver el compromiso 508fd8e (29 de junio de 2020) de Đoàn Trần Công Danh ( sgn
) .
Consulte la confirmación 0068f21 , la confirmación a471214 , la confirmación 0cc1b47 , la confirmación 32ba12d , la confirmación 6069ecc , la confirmación f0a96e8 , la confirmación 4d04658 (24 de junio de 2020) y la confirmación 489947c (23 de junio de 2020) por Johannes Schindelin ( dscho
) .
Consulte la confirmación 8747ebb (24 de junio de 2020) de Don Goodman-Wilson ( DEGoodmanWilson
) .
(Fusionada por Junio C Hamano - gitster
- encommit 11cbda2 , 06 de julio de 2020)
init
: permite especificar el nombre de la rama inicial para el nuevo repositorio
Firmado por: Johannes Schindelin
Hay un número creciente de proyectos y empresas que desean cambiar el nombre de la sucursal principal de sus repositorios (consulte, por ejemplo, el tweet de Mislav Marohnić para conocer los antecedentes al respecto).
Para cambiar ese nombre de rama para nuevos repositorios, actualmente la única forma de hacerlo automáticamente es copiando todo el directorio de plantillas de Git, luego codificando el nombre de rama predeterminado deseado en el .git/HEAD
archivo y luego configurándolo init.templateDir
para apuntar a esos archivos de plantilla copiados.
Para hacer este proceso mucho menos engorroso, vamos a introducir una nueva opción: --initial-branch=<branch-name>
.
git init --initial-branch=hello myLocalRepo
# or
git config --global init.defaultBranch hello
git init myLocalRepo
Y:
init
: permite configurar el nombre predeterminado de la rama inicial a través de la configuración
Ayudado por: Johannes Schindelin
Ayudado por: Derrick Stolee
Firmado por: Don Goodman-Wilson
Acabamos de introducir la opción de línea de comandos --initial-branch=<branch-name>
para permitir la inicialización de un nuevo repositorio con una rama inicial diferente a la codificada.
Para permitir a los usuarios anular el nombre de la rama inicial de forma más permanente (es decir, sin tener que especificar el nombre manualmente para todas y cada una de las git init
invocaciones), introduzcamos la init.defaultBranch
configuración de configuración.
Nota: la confirmación 489947c , sobre el mensaje de confirmación de fusión, se ha revertido desde entonces en Git 2.29, consulte " ¿Cómo puedo personalizar el mensaje de confirmación de fusión de git? ".
El init.defaultBranch
escenario permanece.
Esto afecta a los submódulos:
submodule
: recurrir a HEAD del control remoto por falta de control remoto.
Ayudado por: Philippe Blain
Firmado por: Johannes Schindelin
Cuando remote.<name>.branch
no está configurado, git submodule update
actualmente vuelve a usar el nombre de la rama master
.
Sin embargo, una idea mucho mejor es usar el control remoto HEAD
: en todos los servidores Git que ejecutan versiones de Git razonablemente recientes, el symref HEAD
apunta a la rama principal.
Nota: t7419 demuestra que puede haber casos de uso que esperan git submodule update --remote
actualizar submódulos a la master
rama remota incluso si el remoto HEAD
apunta a otra rama.
Podría decirse que este parche hace que el comportamiento sea más intuitivo, pero existe una pequeña posibilidad de que esto provoque regresiones en configuraciones poco claras.
Aun así, debería estar bien corregir este comportamiento sin nada como un período de transición más largo:
- El
git submodule update --remote
comando no es realmente común.
- El comportamiento actual de Git al ejecutar este comando es completamente confuso, a menos que la rama actual del repositorio remoto lo sea
master
(en cuyo caso el comportamiento propuesto coincide con el comportamiento anterior).
- Si un usuario encuentra una regresión debido al comportamiento cambiado, la solución es en realidad trivial: la configuración
submodule.<name>.branch
en master
restablecerá el comportamiento anterior.
Tenga en cuenta que, con Git 2.29 (Q4 2020), las pruebas contrib/
se ajustan al cambio reciente a fmt-merge-msg
.
Consulte la confirmación b87528c (3 de agosto de 2020) de Emily Shaffer ( nasamuffin
) .
(Combinado por Junio C Hamano - gitster
- en el compromiso 83b8250 , 10 de agosto de 2020)
Revert "contrib
:: subtree
ajuste la prueba para cambiar en fmt-merge-msg
"
Firmado por: Emily Shaffer
Esto revierte el compromiso 508fd8e8baf3e18ee40b2cf0b8899188a8506d07 .
En 6e6029a8 ( fmt-merge-msg
: permitir que el destino de la fusión se omita de nuevo) recuperamos el comportamiento donde se fusiona con ' master
', por defecto, no incluimos " into 'master'
" al final del mensaje de fusión. Esta corrección de prueba ya no es necesaria.
También:
Con Git 2.29 (Q4 2020), actualice las pruebas para eliminar la palabra ' master
' de ellas.
Consulte la confirmación f33f2d3 , la confirmación b6211b8 (26 de septiembre de 2020) y la confirmación 432f5e6 , la confirmación 5a0c32b , la confirmación 659288c (21 de septiembre de 2020) de Johannes Schindelin ( dscho
) .
(Combinado por Junio C Hamano - gitster
- en el compromiso 58138d3 , 05 de octubre de 2020)
tests
: evitar variaciones del master
nombre de la rama
Firmado por: Johannes Schindelin
El término master
tiene una historia cargada que sirve como un recordatorio constante de la injusticia racial. El proyecto Git no tiene ningún deseo de perpetuar esto y ya comenzó a evitarlo.
El conjunto de pruebas usa variaciones de este nombre para ramas distintas de la predeterminada. Aparte de t3200, donde acabamos de abordar esto en la confirmación anterior, esas instancias se pueden renombrar de manera automatizada porque no requieren ningún cambio fuera del script de prueba, así que hagámoslo.
Dado que las ramas tocadas tienen muy poco (si es que tienen algo) que ver con la rama predeterminada, elegimos usar un esquema de nomenclatura completamente separado: topic_<number>
(no puede ser topic-<number>
porque t5515 usa la test_oid
maquinaria con el término y esa maquinaria usa variables de shell internamente cuyos nombres no pueden contener guiones).
Este truco fue realizado por esta invocación sed (GNU):
$ sed -i 's/master\([a-z0-9]\)/topic_\1/g' t/t*.sh
Y, todavía con Git 2.29:
Consulte la confirmación 538228e , la confirmación a15ad5d (08 de octubre de 2020) de Johannes Schindelin ( dscho
) .
(Combinado por Junio C Hamano - gitster
- en el compromiso 62564ba , 08 de octubre de 2020)
t1415
: evite usar main
como nombre de referencia
Firmado por: Johannes Schindelin
En preparación para una serie de parches que cambiará la alternativa init.defaultBranch
a main
, no usemos main
como nombre de referencia en este script de prueba.
De lo contrario, el ( hombre ) que quiere atrapar a esos árbitros también atraparía inesperadamente .git for-each-ref ... | grep main
refs/heads/main
Dado que las referencias en cuestión son locales de árbol de trabajo (es decir, cada árbol de trabajo tiene las suyas propias, como HEAD
), y dado que el caso de prueba ya usa un árbol de trabajo secundario llamado " second
", usemos el nombre " first
" para esas referencias.
Mientras lo hace, ajuste los títulos de prueba que hablan de un "repositorio" cuando se referían a un "árbol de trabajo".