Preguntas más frecuentes sobre Git

En primer lugar, compruebe que tiene configurado un origin repositorio. Si ha clonado el repositorio con git clone, ya tiene uno. Al consultar una rama que no existe localmente, Git determina si existe una rama remota con el mismo nombre. Si es así, Git crea una rama local que hace referencia a la rama remota. Use git pull para descargar las confirmaciones y actualizar el historial de la rama localmente.

Ejecute git branch sin argumentos para mostrar las ramas locales y resaltar la que has cambiado. En Visual Studio, la barra de estado muestra la rama actual al trabajar con un proyecto almacenado en un repositorio Git local.

Realice confirmaciones independientes para cambios lógicos distintos. Piensa en las confirmaciones como entradas en un libro de registro. Cada vez que hagas un cambio que valga la pena anotar, regístralo en un commit. Un enfoque popular es permitir confirmaciones locales frecuentes, pero consolidarlas a través de el rebase antes de subir. Este enfoque proporciona flexibilidad al tiempo que se mantiene optimizado el historial de confirmaciones.

En proyectos grandes con muchas confirmaciones y colaboradores, el historial de main ramas puede reflejar el desarrollo de ramas temáticas más que el progreso general del proyecto. Puede condensar confirmaciones en ramas mediante combinación y rebase. Las confirmaciones de squash simplifican el historial de ramas y generan una rama principal más limpia después de combinar.

Use el comando git blame para averiguar quién realizó un cambio determinado en un archivo. En el repositorio local, ejecute git blame con el -L parámetro para especificar las líneas de interés. Blame genera una salida con formato que muestra la confirmación que actualizó por última vez cada línea y el autor de ese cambio.

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame busca en el historial de confirmaciones. También puede revisar el historial de un archivo en el portal web para determinar quién realizó un cambio y cuándo. Abra el Explorador de código para el repositorio y la rama y, a continuación, seleccione el archivo que desea examinar. Azure Repos muestra un historial de confirmaciones completo para ese archivo en la rama actual.

Cambiar a otra rama en Git afecta el estado de los archivos del sistema de archivos. Git usa el historial de confirmaciones para asegurarse de que el directorio de trabajo coincide con la rama seleccionada. Si intenta cambiar las ramas mientras no se han confirmado los cambios, esos cambios se sobrescriben durante la finalización de la compra. Para evitar la pérdida accidental de datos, Git bloquea el checkout. Tiene las siguientes opciones:

• Abandone los cambios y vuelva al commit más reciente. Consulte la sección deshacer los cambios en Git para obtener instrucciones sobre cómo revertir a la confirmación más reciente.
• Confirme los cambios. Consulte guardar su trabajo en Git con commits.
• Guarde el trabajo actual para guardar los cambios para más adelante y restablecer el área de trabajo a la última confirmación.

Este problema se produce debido a conflictos de combinación en archivos binarios grandes. El límite de tamaño de archivo actual es de 100 MB. Para solucionar este problema, fusione el destino con el origen localmente, resuelva los conflictos y haga push de los cambios.

Use Git LFS (almacenamiento de archivos grandes) para archivos binarios de gran tamaño para evitar conflictos y administrar el tamaño general del repositorio, lo que afecta a los tiempos de clonación e inserción.

Para guardar los cambios sin confirmarlos, use Git stash. Este comando guarda los cambios preparados y no preparados actuales en la rama y revierte la rama al estado del último commit. A continuación, puede cambiar a otra rama, completar el trabajo y, después, ejecutar stash apply para restaurar los cambios.

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

Al ejecutar git stash apply, los cambios guardados más recientemente se aplican a la rama actual. Si hay algún conflicto de archivos, stash restaura los archivos que no tienen conflictos y crea marcadores de conflicto en los archivos restantes. Resuelva los conflictos manualmente.

Cuando ya no necesite el almacenamiento provisional, elimínelo con git stash drop. Este comando elimina el stash más reciente.

Puede tener múltiples stashes, pero debe aplicar y eliminar explícitamente cada uno. Para más información, consulte la documentación de Git Stash.

De forma predeterminada, Git usa un editor de línea de comandos cuando solicita mensajes de confirmación, realiza rebases y controla otras tareas que requieren entrada. Configure el editor predeterminado con git config:

> git config core.editor _path_to_editor_ _options_to_editor_

Git para Windows facilita la configuración del Bloc de notas como editor:

> git config core.editor notepad

Este comando configura el Bloc de notas de Windows para controlar la edición de texto de Git. También puede especificar un ancho de columna preferido para los mensajes de confirmación:

> git config format.commitMessageColumns 72 

Esta configuración envuelve el texto del mensaje de confirmación en el ancho de columna preferido de 72 caracteres.

Git incluye un nombre de usuario y una dirección de correo electrónico en cada confirmación, y Azure Repos usa esta información cuando muestra confirmaciones y solicitudes de incorporación de cambios. Para actualizar el nombre y el correo electrónico en la línea de comandos, use el git config comando :

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

La opción --global establece el correo electrónico y el nombre incluidos en las confirmaciones en todos los repositorios de Git de este sistema. Para cambiar la configuración de un único repositorio, vaya al directorio del repositorio y ejecute los comandos anteriores sin la --global marca .

También puede cambiar la configuración de nombre y correo electrónico desde Visual Studio. En el menú Git , seleccione Configuración. En el cuadro de diálogo Opciones, seleccione Configuración global de Git o Configuración> general del repositorio de Git.

Habilite el rastreo detallado para obtener información detallada del error. Establezca las siguientes variables de entorno antes de ejecutar el comando de Git:

set GIT_TRACE=1
set GIT_TRACE_PACKET=1
set GIT_CURL_VERBOSE=1

La salida de seguimiento ayuda a determinar si el error está relacionado con la conectividad de red, la configuración del proxy, los certificados SSL o la autenticación. Para obtener más información sobre las variables de entorno de Git, consulte Git Internals - Environment Variables( Variables de entorno de Git).

Si está detrás de un servidor proxy y Git no está configurado para usarlo, las operaciones de clonación y envío producirán errores de 407, 502, o "no se puede acceder".

Ejecute git config --list para comprobar si un proxy ya está configurado. Si no es así, establezca el proxy globalmente:

> git config --global http.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

Para configurar un proxy solo para una dirección URL específica:

> git config --global http.https://dev.azure.com.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

Para más información, consulte la documentación de configuración de Git.

Si tu contraseña cambió o las credenciales almacenadas en caché están obsoletas, las operaciones de clonado o push de Git fallan con errores de autenticación. Restablezca el Administrador de credenciales de Git (GCM) para resolver el problema:

> git config --global --unset credential.helper
> git config --global credential.helper manager

También puede quitar las credenciales almacenadas en caché directamente en el Administrador de credenciales de Windows:

1. Abra elPanel de control>Cuentas de usuario>Administrador de credenciales.
2. Seleccione Credenciales de Windows.
3. Busque y quite entradas para git:https://dev.azure.com/<orgname>.

Como alternativa, use la línea de comandos:

> cmdkey /list | findstr "git"
> cmdkey /delete:git:https://dev.azure.com/<orgname>

En macOS, ejecute git credential reject para borrar las credenciales almacenadas:

echo url=https://dev.azure.com/<orgname> | git credential reject

Después de borrar las credenciales, vuelva a intentar la operación de clonación o push. Git le pide que vuelva a autenticarse.

Al clonar o insertar en una instancia de Azure DevOps Server que usa un certificado autofirmado o de entidad de certificación interna, Git produce un error:

fatal: unable to access '...': SSL certificate problem: unable to get local issuer certificate

Opción 1: Usar Windows SChannel (recomendado en Windows)

Configurar Git para usar el almacén de certificados de Windows en lugar del conjunto de certificados de CA de OpenSSL. Si Windows confía en el certificado o ca del servidor, no se necesitan pasos adicionales:

> git config --global http.sslBackend schannel

Para obtener más información sobre cómo configurar el back-end SSL en Visual Studio, consulte Configuración de Git: proveedor de red criptográfico.

Opción 2: Apuntar Git al certificado de CA

Exporte el certificado de autoridad de certificación raíz o intermedia como un archivo codificado .crt en Base 64 y luego indíquele a Git dónde encontrarlo.

> git config --global http.sslCAInfo C:/Users/<yourname>/my-ca-cert.crt

También puede agregar el certificado al paquete de CA existente de Git (normalmente en C:\Program Files\Git\mingw64\etc\ssl\certs\ca-bundle.crt) en lugar de sobrescribir todo el paquete.

Para escenarios de agente de canalización con certificados autofirmados, consulte Ejecutar un agente autohospedado detrás de un proxy o con certificados autofirmados.

Contenido relacionado

• Documentación de Git de Azure Repos
• Clonación de un repositorio de Git existente
• Almacenamiento del trabajo con confirmaciones
• Usa ramas de Git