Preguntas más frecuentes sobre Git

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

git branchsin argumentos muestra las ramas locales y resalta las que ha comprobado. 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 es realizar confirmaciones independientes para cambios separados lógicamente. Piense en las confirmaciones como entradas en un cuaderno de registros. Cada vez que realice un cambio que merece la pena mencionar, aráctelo en una confirmación. Una opción popular es permitir que todos los usuarios se confirmen localmente tanto como quieran, pero antes de insertar las confirmaciones locales, primero las presionan mediante el cambio de nivel. Esta opción proporciona a los usuarios flexibilidad para realizar confirmaciones frecuentes, a la vez que se mantiene optimizado el historial de confirmaciones.

Los proyectos grandes con muchas confirmaciones y una variedad de colaboradores pueden dar lugar a historiales de confirmación para la rama que representa el historial de desarrollo de las ramas de tema combinadas en más que el historial de desarrollo del proyecto mainmain global. Git proporciona una instalación para condensar confirmaciones en ramas mediante la eliminación de confirmaciones y el rebasado. Al eliminar confirmaciones, el historial de confirmaciones en una rama es menos detallado y hace que el historial de confirmaciones en la rama principal sea más sencillo una vez combinado.

Use el git blame comando para averiguar quién realizó un cambio determinado en un archivo. Desde el repositorio local, puede ejecutar git blame con el parámetro , -L especificando qué líneas de interés. Blame genera una salida con formato que muestra la confirmación que actualizó por última vez la línea, así como 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 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, haga clic en el archivo de interés. Azure Repos mostrará un historial de confirmación completo para ese archivo en la rama actual.

La comprobación en otra rama de Git afectará al estado de los archivos en el sistema de archivos. Git usa el historial de confirmaciones para asegurarse de que está trabajando con los archivos que representan el estado de la rama. Si intenta cambiar las ramas mientras tiene cambios no confirmados, esos cambios se sobrescribirán durante la des check-out. Dado que Git no quiere que pierda accidentalmente los cambios, impide que se realice el des check-out. Tiene dos opciones:

• Abandone los cambios y vuelva a la confirmación más reciente. Consulte Deshacer cambios en Git para obtener instrucciones sobre cómo revertir a la confirmación más reciente.
• Confirme los cambios. Vea guardar el trabajo en Git con confirmaciones.
• Almacenamiento escalonado del trabajo actual, guardado de los cambios para más adelante y limpieza del área de trabajo en la última confirmación.

A veces desea conservar los cambios, pero no confirmarlos porque no están en un punto en el que se sienta cómodo. Use Git stash . El stash toma los cambios actuales en fases y sin etiquetar en la rama y guarda el trabajo y, a continuación, devuelve la rama al estado de la última confirmación. Puede cambiar a la otra rama, realizar su trabajo y, cuando vuelva a esta rama, ejecute 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 los cambios de tamaño escalonado más git stash apply recientes, se aplicarán a la rama actual. Si hay un conflicto en el que se aplican los cambios escalonados, restaurará los cambios de los archivos que no entren en conflicto y creará marcadores de conflicto en los archivos que entren en conflicto para que pueda stash resolverlos. En este caso, debe combinar los cambios manualmente.

Una vez que haya terminado con el valor de stash, elimínelo con Este comando quita el último conjunto de cambios git stash drop en el sistema.

Puede tener varios escalones, pero esto requiere más manipulación manual, ya que tiene que aplicar y quitar escalones explícitamente. Obtenga más información en la documentación de Git Stash.

De forma predeterminada, Git de línea de comandos usará un editor de línea de comandos al solicitar mensajes de confirmación, realizar rebases y 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 For Windows facilita la configuración del Bloc de notas como editor:

> git config core.editor notepad

Lo que configurará Windows de Bloc de notas editar la información de Git según sea necesario y pasar correctamente el texto de Git a Bloc de notas. También puede especificar

> git config format.commitMessageColumns 72 

Para mantener las columnas de texto de los mensajes de confirmación en los 72 y el ajuste de línea preferidos después de alcanzar ese límite de caracteres en una línea.

Git coloca un nombre de usuario y una información de dirección de correo electrónico dentro de cada confirmación, y Azure Repos usa esta información al ver confirmaciones y al trabajar con solicitudes de extracción. Si está trabajando en la línea de comandos, puede actualizar el nombre y la información de correo electrónico que se muestran mediante el git config comando :

> git config --global user.email "frank@fabrikam.com"
> git config --global user.name "Francis Totten"

La --global opción establecerá el correo electrónico y el nombre incluidos en las confirmaciones de todos los repositorios de Git en este sistema. Si desea cambiar la configuración de un único repositorio, debe cambiar al directorio donde se encuentra el repositorio de Git y ejecutar los comandos anteriores sin la --global marca .

También puede cambiar el nombre y la configuración de correo electrónico desde Visual Studio. En Team Explorer, elija Configuración y, en Git,haga clic en el vínculo Configuración globalConfiguración repositorio.