Preguntas más frecuentes sobre Git

En primer lugar, asegúrese de que tiene configurado un repositorio origin. Debe tener esto si ha clonado el repositorio mediante git clone. Cuando se extrae del repositorio una rama que no existe localmente, Git comprueba si hay una rama remota con el mismo nombre. Si existe, Git crea una rama local que hace referencia a la rama remota con ese nombre. 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 ha extraído del repositorio. En Visual Studio, la barra de estado también muestra la rama actual cuando se trabaja con un proyecto almacenado en un repositorio de Git local.

Es una práctica recomendada realizar confirmaciones separadas para cambios lógicamente distintos. Las confirmaciones son como las entradas de un libro de registro. Cada vez que realice un cambio que vale la pena anotar, debe registrarlo en una confirmación. Un enfoque popular es permitir confirmaciones locales frecuentes, pero combinarlas a través de un cambio de base antes de insertar. Esto proporciona flexibilidad a la vez que mantiene optimizado el historial de confirmaciones.

Los proyectos grandes con muchas confirmaciones y colaboradores pueden dar lugar a un historial de sucursales main que refleje el desarrollo de ramas de temas más que el proyecto general. Git permite condensar confirmaciones en ramas a través de la combinación de confirmaciones y el cambio de base. La combinación de confirmaciones hace que el historial de la rama sea menos detallado, lo que simplifica el historial de confirmaciones en la rama principal una vez fusionada.

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 parámetro -L y especifique las líneas que le interesan. Blame genera una salida con formato que muestra la confirmación que actualizó la línea por última vez 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, luego, seleccione el archivo que le interesa. Azure Repos muestra un historial de confirmaciones completo para ese archivo en la rama actual.

Si extrae del repositorio una rama diferente en Git afectará al estado de los archivos del sistema de archivos. Git usa el historial de confirmaciones para garantizar que se trabaja con los archivos que representan el estado de la rama. Si intenta cambiar de rama mientras hay cambios pendientes de confirmación, esos cambios se sobrescribirán al extraerla del repositorio. Dado que Git no quiere que los cambios se pierdan accidentalmente, impide realizar la extracción del repositorio. Tiene dos opciones:

• Abandone los cambios y vuelva a la confirmación 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. Vea Almacenamiento del trabajo en Git con confirmaciones.
• Guarde provisionalmente el trabajo actual, guarde los cambios para más adelante y limpie el área de trabajo en la última confirmación.

Este problema está relacionado con conflictos de combinación en archivos binarios grandes. El límite actual de los archivos es de 100 MB. La solución alternativa es resolver los conflictos de combinación localmente mediante la combinación del destino en el origen localmente, la resolución de conflictos y la inserción de los cambios.

Se recomienda Git LFS (almacenamiento de archivos de gran tamaño) para almacenar archivos binarios grandes, no solo para evitar conflictos, sino también para administrar el tamaño general del repositorio, lo que afecta a los tiempos de clonación e inserción.

Si desea guardar los cambios sin confirmarlos, use Git stash. Guardar provisionalmente guarda los cambios "staged" y "unstaged" actuales de la rama y revierte la rama al estado de la última confirmación. A continuación, puede cambiar a otra rama, realizar 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 provisionalmente más recientes 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 sí lo están. En este caso, debe fusionar mediante combinación los cambios de forma manual.

Una vez que haya terminado de guardar provisionalmente, elimínelo con [git stash drop]. Este comando quita el último conjunto de cambios guardados provisionalmente.

Puede haber varios trabajos guardados provisionalmente, pero su administración requiere una mayor manipulación manual, ya que hay que aplicar y anular de forma explícita los trabajos guardados provisionalmente. Obtenga más información en la documentación de Git sobre cómo guardar provisionalmente.

De forma predeterminada, Git de línea de comandos usa un editor de línea de comandos al solicitar mensajes de confirmación, realizar fusiones mediante cambio de base y efectuar otro trabajo que requiera información adicional para completarse. El editor predeterminado se configura mediante 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 correctamente el texto de Git al Bloc de notas. También puede especificar lo siguiente:

> git config format.commitMessageColumns 72 

De este modo, las columnas de texto de los mensajes de confirmación se mantendrán en el valor preferido de 72 y la línea se encapsulará tras alcanzar ese límite de caracteres en una línea.

Git incluye información sobre el nombre de usuario y la dirección de correo electrónico en cada confirmación, y Azure Repos usa esta información al visualizar las confirmaciones y trabajar con PR. Si está trabajando en la línea de comandos, puede actualizar la información de nombre y correo electrónico que se muestra mediante el comando git config:

> 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. Si quiere cambiar la configuración de un solo repositorio, debe cambiar al directorio donde se encuentra el repositorio de Git y ejecutar los comandos anteriores sin la marca --global.

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 Git Global Settings (Configuración global de Git) o Configuración de repositorios de Git>General.

Visual Studio 2019, versión 16.8 y versiones posteriores, proporciona una experiencia de control de versiones de Git al tiempo que mantiene la interfaz de usuario de Git de Team Explorer. Para usar Team Explorer, desactive Herramientas>Opciones>Características en versión preliminar>Nueva experiencia de usuario de Git en la barra de menús. Puede usar ejecutar características de Git indistintamente desde cualquier interfaz.

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