Preguntas más frecuentes sobre Git

En primer lugar, asegúrese de 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. Fusionar commits simplifica el historial de ramas, lo que hace que el historial de confirmaciones en la rama principal sea más limpio después de la combinación.

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 la línea y el nombre de la persona que realizó la confirmación.

> 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 automáticamente 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 de interés. 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 garantizar que se esté trabajando con archivos que representan el estado de su rama. 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 cambios, Git bloquea la desprotección. Tiene estas opciones:

• Abandone los cambios y vuelva al commit más reciente. Consulte Anulación de 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.
• Almacenar provisionalmente tu trabajo actual, guardar los cambios para después y limpiar el área de trabajo hasta el último commit.

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 un conflicto, stash restaura los cambios de los archivos que no entran en conflicto y crea marcadores de conflicto en los archivos que entran en conflicto. Combine los cambios manualmente en este caso.

Después de terminar con el almacenamiento provisional, elimínelo con git stash drop. Este comando quita el último conjunto de cambios guardados provisionalmente.

Puede tener varios almacenamientos temporales, pero administrarlos requiere un trabajo más manual, ya que debe aplicar y eliminar explícitamente cada uno. Para más información, consulte la documentación de Git Stash.

De forma predeterminada, Git de línea de comandos usa un editor de línea de comandos cuando solicita mensajes de confirmación, realiza rebases y lleva a cabo otro trabajo que requiere información adicional. 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 editar la información de Git según sea necesario y pasar el texto correctamente entre Git y el Bloc de notas. También puede especificar lo siguiente:

> git config format.commitMessageColumns 72 

Esta configuración mantiene las columnas de texto en los mensajes de confirmación en el ancho de 72 caracteres preferido y ajusta las líneas en ese límite.

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 al mostrar confirmaciones y trabajar con solicitudes de incorporación de cambios. Para actualizar la información de nombre y 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 donde se encuentra el repositorio de Git 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.

Visual Studio 2019, versión 16.8 y versiones posteriores, proporcionan una experiencia de control de versiones de Git mientras se mantiene la interfaz de usuario de Git de Team Explorer . Para usar Team Explorer, desactive Herramientas>Opciones>Características de Vista Previa>Nueva experiencia de usuario de Git en la barra de menús. Puede usar características de Git desde cualquier interfaz.

En Team Explorer, elija Configuración y, en Git, seleccione el vínculo Configuración global o Configuración de repositorios.

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 del seguimiento ayuda a identificar 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.