Comprender cómo se asignan los comandos de Control de versiones de Team Foundation (TFVC) a los flujos de trabajo de Git
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Visual Studio 2019 | Visual Studio 2022
¿Planea adoptar Git, está familiarizado con las acciones TFVC y se pregunta cómo se corresponden con Git? Ambos son sistemas de control de código fuente potentes y maduros. Sin embargo, trasladar las acciones comunes a las que se ha acostumbrado en uno al otro puede ser una experiencia confusa.
Este artículo no profundiza en los comandos de Git, ya que están bien documentados en la documentación del producto, sino que muestra ejemplos para ayudarle a tomar las decisiones correctas, mientras se mueve a través de un flujo de trabajo típico de crear -> clonar -> rama -> cambiar -> confirmar -> insertar área de trabajo.
Empiece por el principio creando un nuevo repositorio
Cada proyecto puede hospedar repositorios TFVC y Git en el mismo proyecto, crear un TFVC y uno o varios repositorios de Git.
Una vez creado el repositorio, se le presentan instrucciones paso a paso para empezar a trabajar rápidamente.
Haga clic en Crear un archivo Léame al final de la página de instrucciones para proporcionar el contexto del repositorio y crear algún historial.
Creación de un área de trabajo y obtención de la versión más reciente
Al conectarse a un repositorio de TFVC por primera vez, normalmente se crea un área de trabajo y se obtiene el código más reciente. Entonces, ¿cómo empezar a trabajar en Git?
De forma similar a un área de trabajo de TFVC, clone el repositorio de Git en una carpeta del equipo. La clonación descargará todo el contenido y el historial del repositorio en el equipo local. Una vez que tenga el repositorio clonado, casi todas las operaciones se realizan localmente. Puede trabajar sin conexión con una copia de seguridad completa del repositorio centralizado.
git clone https://dev.azure.com/demo-fabrikam/Fabrikam/_git/Mapping-TFVC-actions-to-Git
Solo tiene que clonar una vez por repositorio, pero, al igual que las áreas de trabajo de TFVC, puede tener varios clones para aislar el trabajo en curso. Sin embargo, la creación de una rama suele ser una manera mejor de aislar los cambios.
Crear una rama
Con Git, siempre está trabajando en una rama y de forma predeterminada en lamain rama. Se recomienda crear varias ramas locales. Es un proceso que tarda segundos y permite cambiar de contexto sin problemas entre ramas y trabajar de forma aislada. A diferencia de las ramas de TFVC, que tienen como ámbito las rutas de acceso, las ramas de Git tienen ámbito de repositorio. Son ligeras, solo pueden ser locales o compartirse con otros cuando esté listo para compartir los cambios.
Considere la posibilidad de crear ramas si necesita trabajar de forma aislada, debe suspender el trabajo, centrarse en las nuevas características o si planea realizar una solicitud de incorporación de cambios de Git.
Como usuario de TFVC, repita varias veces lo siguiente:
- Se recomienda la creación de ramas.
- La creación de ramas de Git es económica, rápida y eficaz.
- Git recomienda usar ramas locales.
- Publique ramas locales en el repositorio centralizado según sea necesario.
- Compruebe siempre el contexto de la rama antes de realizar cambios.
- Asigne un nombre a la rama mediante una convención común, como users/alias/branchname, por ejemplo: users/doris/newfeature
Cree y cambie a una rama puntual local, denominada francis/demo-feature. Es una buena práctica ejecutar primero un git status, para verificar que se encuentra en la rama correcta para empezar.
git checkout -b francis/demo-feature
Realizar un cambio agregando archivos
De forma similar a la experiencia de TFVC, los nuevos archivos de la carpeta de trabajo no forman parte automáticamente del repositorio. Los archivos nuevos se almacenan provisionalmente con el comando git add, que es sinónimo de realizar una operación add Items to Folder en TFVC.
git add <file>
o
git add --all
Con el ejemplo preconfigurado, tendrá 13 archivos nuevos que se han incluido y almacenado provisionalmente en el repositorio local.
Ver los cambios pendientes
¿Qué cambios se están produciendo ahora en su entorno de trabajo? Como antes, el comando de Git status o la vista Changes en el IDE de Visual Studio mostrarán los cambios en su árbol de trabajo.
git status
Inserción de cambios y confirmación local
En TFVC, comparte los cambios con Insertar en el repositorio, que envía los cambios pendientes al servidor. El proceso de Git es un poco diferente. En primer lugar, se confirma en el repositorio local, se crea un objeto de confirmación (como un conjunto de cambios) y, después, se inserta para enviar esos cambios al servidor.
Los cambios se confirman en el repositorio local utilizando git commit, similar a un Checkin Pending Changes en TFVC. Una diferencia clave es que el git commit confirma los cambios en el repositorio local en lugar de en el repositorio remoto.
git commit
Inserción de los cambios con el repositorio remoto o el servidor
En primer lugar, debe publicar la rama local francis/demo-feature en el servidor remoto, que incluye todos los cambios confirmados.
git push --set-upstream origin francis/demo-feature
Para sincronizar más actualizaciones en el entorno local con el repositorio remoto, debe insertar los cambios mediante git push. La práctica recomendada con el comando Git o el IDE de Visual Studio consiste en:
fetchpara descargar contenido y obtener una vista previa de los cambios entrantes de otros usuarios.pullpara descargar y, después, combinar los cambios de otros usuarios.pushpara compartir los cambios locales.
Visualización del historial
Para ver la confirmación que acaba de crear puede revisar el historial local.
Para obtener un historial compacto, use:
git log --oneline
Para obtener una vista detallada, use:
git log
Como se muestra anteriormente, git log enumera el autor, el correo electrónico, la fecha escrita y la suma de comprobación SHA-1 de confirmación. Como usuario de TFVC, puede usar la opción --stat para incluir más información, como el nombre de archivo y las estadísticas de cambio.
También puede ver el historial del repositorio centralizado mediante el portal web de Azure DevOps Services.
En el portal web de Azure DevOps Services, seleccione CÓDIGO > Historial o CÓDIGO > Explorador > Historial
Llegados a este punto, ha explorado con éxito el flujo de trabajo crear -> clonar -> rama -> cambiar -> confirmar -> insertar flujo de trabajo, basado en acciones comunes de TFVC.
También tiene la opción de emitir una solicitud de incorporación de cambios para publicar y almacenar provisionalmente los cambios en el repositorio remoto o servidor en este momento.
Otras acciones
Cambio de rama
Al trabajar con Git, no cambia las ramas cambiando a carpetas y ubicaciones independientes del equipo. Para cambiar el contexto, haga un checkout, haciendo que todo el directorio de trabajo coincida con la rama o confirmación seleccionada. ¡Rápido y simple!
Línea de comandos
git checkout <branch>
Si olvidó qué ramas tiene en el repositorio local, use git branch para enumerar las ramas predeterminadas y conocidas.
Tenga en cuenta en qué rama está trabajando. Cuando se trabaja con varias ramas en Git, se cambian las ramas en su lugar en el mismo directorio de trabajo. Cambiar entre ramas es una operación rápida y asegurarse de que está en la rama correcta en todo momento es una buena práctica.
Obtener la última versión
Hay muchas razones para querer obtener actualizaciones. Por ejemplo, cuando necesite cambiar el contexto a otro proyecto, actualice el equipo de desarrollo con la versión más reciente del código base.
Línea de comandos
git pull
o
git fetch
seguido de
git merge FETCH_HEAD
Obtenga siempre la versión más reciente y resuelva los conflictos de combinación localmente.
Deshacer cambios locales
Puede haber un motivo válido para revertir todas las revisiones realizadas en el repositorio local y restablecer el entorno de trabajo a la versión más reciente desde el repositorio remoto.
Línea de comandos
git reset --hard HEAD
seguido de
git pull origin
seguido de
git clean -xdf
El escenario es sinónimo de hacer un Get > Latest Version con las opciones Overwrite writable files that are not checked out y Overwrite all files if the local version matches the specified version en TFVC.
Como alternativa, puede eliminar manualmente el repositorio local (después de realizar una copia validada) y, después, clone de nuevo el repositorio.
Hay muchas más acciones y opciones disponibles para los usuarios de Git. Estos son algunos sitios de referencia útiles para su lectura adicional:
- Comandos de Git descritos en este documento, consulte la documentación de Git
- Piense como (a) Git, una guía para Perplejos.
- Cómo deshacer (casi) cualquier cosa con Git, de Joshua Wehner
Preguntas y respuestas
¿Qué ocurre con la sincronización?
"¿El IDE de Visual Studio Commit and Sync no hace todo esto por arte de magia?", se estará preguntando.
Seleccione Git>Confirmar o Guardar provisionalmente para abrir Cambios de Git. Seleccione el menú desplegable Confirmar todo y luego Confirmar todo y sincronizar.
O bien, en Team Explorer, seleccione el menú desplegable Confirmar y luego Comando y sincronización.
¡La magia conlleva responsabilidad! A muchos usuarios no les gusta la sync ya que a veces puede desordenar su historial local y agregar una confirmación de combinación sobre su confirmación actual. Una vez que se encuentra en un estado incorrecto, debe revertir a la línea de comandos, ya que actualmente no hay compatibilidad con el restablecimiento en el IDE.
Autores: Jesse Houwing, Martin Hinshelwood, Mike Fourie y Willy Schaub del ALM | DevOps Rangers. Conéctese con ellos aquí.
(c) 2015 Microsoft Corporation. Todos los derechos reservados. Este documento se proporciona "tal cual". La información y las opiniones expresadas en este documento, incluidas las direcciones URL y otras referencias a sitios web de Internet, pueden cambiar sin previo aviso. Usted asume el riesgo de utilizarla.
Este documento no le proporciona ningún derecho legal sobre ninguna propiedad intelectual de ningún producto de Microsoft. Puede copiar y usar este documento para su uso interno de referencia.