¿Cuál es la diferencia entre push.default "coincidente" y "simple"?

He estado usando Git por un tiempo, pero nunca tuve que configurar un nuevo repositorio remoto y sentí curiosidad por hacerlo. He estado leyendo tutoriales y no sé cómo conseguirlo.git push a trabajar.

Si simplemente uso git push, me pide que vea una "rama predeterminada" para señalar. ¿Cuál es la diferencia entre estas dos opciones que me proporciona?

git config --global push.default matching
git config --global push.default simple

La matchingopción simplemente envía las ramas que tengo en mi repositorio local, y si no coinciden, tengo que decirle manualmente que envíe las nuevas ramas locales que tengo, ¿correcto? ¿Es esta la mejor práctica a utilizar o es la simplemejor?

Feb 18 '14 04:02 Josh

De la documentación de GIT: Git Docs

A continuación se proporciona la información completa. En resumen, simplesolo presionará current working branche incluso entonces solo si también tiene el mismo nombre en el control remoto. Esta es una configuración muy buena para principiantes y se convertirá en la predeterminada enGIT 2.0

Mientras que matchingimpulsará todas las sucursales localmente que tengan el mismo nombre en el control remoto. (Sin importar su rama de trabajo actual). Esto significa que potencialmente se enviarán muchas ramas diferentes, incluidas aquellas que quizás ni siquiera quieras compartir.

En mi uso personal, generalmente uso una opción diferente: currentque impulsa la rama de trabajo actual (porque siempre hago una rama para cualquier cambio). Pero para un principiante sugeriríasimple

push.default

Define la acción git pushque se debe realizar si no se proporciona explícitamente ninguna especificación de referencia. Los diferentes valores son adecuados para flujos de trabajo específicos; por ejemplo, en un flujo de trabajo puramente central (es decir, el origen de la búsqueda es igual al destino de la inserción), upstreamprobablemente sea lo que desee. Los valores posibles son:

• nothing- no envíe nada (error) a menos que se proporcione explícitamente una especificación de referencia. Esto está destinado principalmente a personas que quieren evitar errores siendo siempre explícitos.

• current- presione la rama actual para actualizar una rama con el mismo nombre en el extremo receptor. Funciona tanto en flujos de trabajo centrales como no centrales.

• upstream- empujar la rama actual de regreso a la rama cuyos cambios generalmente se integran en la rama actual (que se llama @{upstream}). Este modo sólo tiene sentido si está enviando al mismo repositorio del que normalmente extraería (es decir, flujo de trabajo central).

• simple- en el flujo de trabajo centralizado, trabaje como upstream con una seguridad adicional para negarse a enviar si el nombre de la sucursal upstream es diferente del local.

  Cuando presione un control remoto que sea diferente del control remoto que utiliza normalmente, trabaje como current. Esta es la opción más segura y adecuada para principiantes.

  Este modo se convertirá en el predeterminado en Git 2.0.

• matching- Empuje todas las ramas que tengan el mismo nombre en ambos extremos. Esto hace que el repositorio que está impulsando recuerde el conjunto de ramas que se expulsarán (por ejemplo, si siempre presiona maint y master allí y ninguna otra rama, el repositorio al que ingresa tendrá estas dos ramas, y su maint y master local). será empujado allí).

  Para usar este modo de manera efectiva, debe asegurarse de que todas las ramas que expulsará estén listas para ser expulsadas antes de ejecutar git push, ya que el objetivo de este modo es permitirle expulsar todas las ramas de una sola vez. Si normalmente termina el trabajo en una sola rama y publica el resultado, mientras que otras ramas están sin terminar, este modo no es para usted. Además, este modo no es adecuado para ingresar a un repositorio central compartido, ya que otras personas pueden agregar nuevas ramas allí o actualizar la información de ramas existentes fuera de su control.

  Este es actualmente el valor predeterminado, pero Git 2.0 cambiará el valor predeterminado a simple.

Feb 18 '2014 22:02 UpAndAdam

Como muestra la respuesta de Adam , ahora push.defaulttiene muchas opciones . Si se encuentra mirando de un lado a otro entre las descripciones para ver las diferencias, intente utilizar este cuadro:

_{¹ simple es el valor de configuración predeterminado desde Git v2.0, lanzado en 2014.
² upstream tiene un alias obsoleto, tracking.
³ nothing requiere que todas las opciones se especifiquen en la CLI.}

Tengo varios repositorios, cada uno de ellos configurado en simple, upstreamy current. Me parece matchingun poco demasiado salvaje para mí, pero puedo imaginar circunstancias en las que resulta útil.

Aug 28 '2023 17:08 Michael come lately

Notas de la versión de Git v2.0

Notas de compatibilidad con versiones anteriores

Cuando git push [$there]no dice qué enviar, hemos utilizado la semántica tradicional de "coincidencia" hasta ahora (todas sus ramas se enviaron al control remoto siempre que ya haya ramas con el mismo nombre allí). En Git 2.0, el valor predeterminado ahora es la semántica "simple", que impulsa:

• solo la rama actual a la rama con el mismo nombre, y solo cuando la rama actual está configurada para integrarse con esa rama remota, si está presionando al mismo control remoto desde el que realiza la búsqueda; o

• solo la rama actual a la rama con el mismo nombre, si está presionando a un control remoto que no es desde donde normalmente realiza la búsqueda.

Puede utilizar la variable de configuración "push.default" para cambiar esto. Si es un veterano y quiere seguir usando la semántica de "coincidencia", puede configurar la variable en "coincidencia", por ejemplo. Lea la documentación para conocer otras posibilidades.

Cuando git add -uy git add -Ase ejecutan dentro de un subdirectorio sin especificar qué rutas agregar en la línea de comando, operan en todo el árbol para mantener la coherencia con git commit -aotros comandos (estos comandos solían operar solo en el subdirectorio actual). Diga git add -u .o git add -A .si desea limitar la operación al directorio actual.

git add <path>es el mismo que git add -A <path>ahora, por lo que git add dir/notará las rutas que eliminó del directorio y registrará la eliminación. En versiones anteriores de Git, git add <path>se utilizaba para ignorar las eliminaciones. Puede decir git add --ignore-removal <path>que se agreguen solo rutas agregadas o modificadas en <path>, si realmente lo desea.

Dec 31 '2015 22:12 CodeWizard