Preguntas más frecuentes sobre Git

En primer lugar, asegúrese de que tiene configurado un repositorio origin. Debe tener un repositorio de este tipo si ha clonado (git clone) el repositorio. Cuando se extrae del repositorio una rama que no existe localmente, Git determina si hay una rama remota con el mismo nombre. Si existe, Git crea una rama local con una referencia a la rama remota con ese nombre. Use git pull para descargar las confirmaciones y hacer que Git se ponga al día del historial de la rama localmente.

Si usa git branch sin argumentos, se mostrarán las ramas locales y aparecerán resaltadas las 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.

La práctica aceptada consiste en realizar confirmaciones independientes para los cambios separados de forma lógica. Las confirmaciones son como las entradas de un libro de registro. Cada vez que realiza un cambio que vale la pena anotar, lo registra en una confirmación. Una opción popular consiste en permitir que todos los usuarios realicen tantas confirmaciones locales como quieran, pero antes de insertarlas, las fusionan mediante combinación con "squash", para lo que llevan a cabo una fusión mediante cambio de base. Esta opción proporciona a los usuarios flexibilidad para realizar confirmaciones frecuentes, a la vez que se simplifica el historial de confirmaciones.

Los proyectos grandes con muchas confirmaciones y diversos colaboradores pueden dar lugar a historiales de confirmación para la rama main que representan el historial de desarrollo de las ramas puntuales combinadas en main mejor que el historial de desarrollo del proyecto general. Git permite condensar confirmaciones en ramas gracias a la fusión de las confirmaciones mediante combinación con "squash" y la fusión mediante cambio de base. Cuando las confirmaciones se fusionan mediante combinación con "squash", el historial de confirmaciones de una rama se vuelve menos detallado, lo que tiene como resultado un historial de confirmaciones más sencillo en la rama principal tras la fusión mediante 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 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 foo.js -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Francis Totten 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 mostrará un historial de confirmaciones completo para ese archivo en la rama actual.

Si extrae del repositorio una rama diferente en Git, esto 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.

A veces interesa mantener los cambios, pero sin confirmarlos porque todavía no es el momento adecuado. Si este es el caso, use stash de Git para guardarlos provisionalmente. Al hacerlo, se toman los cambios "staged" y "unstaged" actuales de la rama, se guarda el trabajo y se devuelve la rama al estado de la última confirmación. Puede cambiar a la otra rama, realizar el trabajo y, cuando vuelva a esta rama, 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 aplicarán a la rama actual. Si se produce un conflicto al aplicar los cambios guardados provisionalmente, stash restaurará los cambios de los archivos que no entran en conflicto, y creará marcadores de conflicto en los archivos con conflicto para que lo solucione. En este caso, debe fusionar mediante combinación los cambios de forma manual.

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

Puede haber varios trabajos guardados provisionalmente, pero esto 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 usará 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 "frank@fabrikam.com"
> git config --global user.name "Francis Totten"

La opción --global establecerá 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.