Este es el segundo artículo de una serie de artículos sobre control de código fuente para administradores de inquilinos de Microsoft 365.
El primer artículo introdujo el control de código fuente y cómo comenzar con Git. En este artículo, aprenderá cómo colaborar con otros usando Git. Esto podría significar trabajar con un compañero de equipo o personas de todo el mundo para colaborar o desarrollar código conjuntamente.
Más desarrolladores significa más complejidad en el control de código fuente
La complejidad de administrar el código aumenta en un orden de magnitud cuando varias personas acceden a la misma base de código. Git te ayuda a gestionar esa complejidad. Cuando combina las capacidades técnicas de Git con procesos y prácticas bien entendidos, puede colaborar con tantos otros desarrolladores como desee. Recuerde, Git se inventó para administrar el código fuente del kernel de Linux con más de 1000 desarrolladores. Sin embargo, aquí nos enfocamos en técnicas que son útiles para un equipo de dos a cinco personas que contribuyen a una base de código.
Diseño del código fuente
Es importante pensar en el directorio y la estructura de archivos de un repositorio de código fuente antes de agregar más colaboradores a un proyecto. Cuando varios colaboradores actualizan una base de código, normalmente hay más cambios para realizar un seguimiento. Algunos de esos cambios ocurren al mismo tiempo. El Colaborador 1 corrige un error, mientras que el Colaborador 2 agrega una nueva característica. Cuando estos dos cambios deben fusionarse nuevamente en la rama principal, es ideal si Git puede hacerlo automáticamente.
A continuación hay dos estrategias para pensar.
Repositorios Múltiples
No es necesario que todo el código fuente de un equipo esté en el mismo repositorio. Usa diferentes repositorios para diferentes proyectos. No cree un repositorio de Git llamado «Scripts de automatización». Esto se convertirá con el tiempo en un gran desastre. Por otro lado, tampoco es práctico crear un repositorio para cada script individual que usted y su equipo administren. Cree repositorios basados en una agrupación lógica de funcionalidad. Por ejemplo, puede tener un repositorio utilizado por su equipo para administrar Intune. Otro repositorio puede contener scripts para automatizar las tareas de administración de usuarios en Azure Active Directory.
Múltiples archivos en un repositorio
La segunda consideración es cómo dividir el código entre archivos dentro de un solo repositorio. Si dos colaboradores trabajan en dos archivos diferentes, Git puede fusionar ambos cambios automáticamente porque no entran en conflicto entre sí. Si dos personas editan el mismo archivo, es posible que un desarrollador deba resolver un conflicto de fusión. La resolución de conflictos de combinación es un tema avanzado que trataré en un artículo futuro.
Si el proyecto es un módulo de PowerShell, considere tener cada función en un archivo separado. Puede usar el archivo PSM1 del módulo para cargar todas las funciones desde archivos separados. Si bien el diseño del módulo de PowerShell no se trata en este artículo, una manera realmente rápida y fácil de hacerlo es obtener todos los archivos en su archivo PSM1. Puede ver una estructura de directorios aquí en la instantánea de VS Code (Figura 1).
Hay un directorio llamado ModuleDemo. En ese directorio se encuentra el archivo ModuleDemo.psm1. Todos los demás archivos que contienen código para las funciones están en el directorio de funciones.
Figura 1: Instantánea del código VS
Esta práctica no solo facilita la administración de cambios con Git, sino que también obliga a los programadores a crear funciones pequeñas de una sola tarea al escribir código. A medida que se expande una base de código, ayudará a minimizar el código duplicado y debería simplificar el proyecto general.
Enviar código a un servidor Git remoto
Mi primer artículo demostró cómo configurar un repositorio git local, cómo realizar cambios y enviarlos al repositorio. La colaboración con los miembros del equipo requiere el uso de algún tipo de servidor Git. Existen docenas de opciones. Microsoft ofrece dos soluciones que pueden usar los administradores de Microsoft 365 y los desarrolladores de .Net.
El primero es Azure DevOps. Azure Dev Ops es la última versión en la nube de lo que solía ser Team Foundation Server. Azure Dev Ops es excelente para proyectos en los que todos los colaboradores de la base de código están en el mismo arrendatario de Azure Active Directory. Es posible agregar usuarios externos desde fuera de la organización, pero esa capacidad dependerá de la configuración B2B en el arrendatario de Azure AD.
La segunda opción es GitHub. Las personas y las empresas usan GitHub para administrar sus repositorios Git. GitHub alberga muchos proyectos populares de código abierto, incluido el propio PowerShell.
Ambos servicios brindan una amplia gama de funciones además de Git, como herramientas de administración de proyectos, herramientas de seguimiento de problemas, automatización de compilación y canalizaciones para implementar código.
Los ejemplos que siguen usan GitHub como un servidor Git remoto. Sin embargo, también se puede usar el mismo proceso para enviar código a Azure Dev Ops.
Agregar un servidor Git remoto
Puede recordar este diagrama del artículo de blog anterior (Figura 2).
Figura 2: Directorio del sistema de archivos Git
Se requiere un paso más para comenzar a compartir código con otros para que pueda tener lugar la colaboración (Figura 3).
Figura 3: Directorio del sistema compartido de archivos Git
Agregar el servidor Git agrega dos pasos más al proceso de confirmación de código, empujar y tirar o buscar. Tirar y traer son similares pero con una diferencia clave. Un pull fusiona los cambios del servidor remoto en su repositorio local. Una búsqueda le dice al repositorio local que hay cambios disponibles en el repositorio remoto sin fusionar los cambios en el repositorio local.
Es importante entender cuándo empujar versus tirar. Al leer un mapa para averiguar cómo ir a algún lugar, debe tener un punto de referencia. Para saber a dónde vas, necesitas saber dónde estás.
Lo mismo es cierto cuando se trata de empujar y extraer código hacia o desde un repositorio Git remoto. La mayoría de las veces, todo es relativo a la rama principal en el repositorio remoto de git. Si desea enviar cambios en un repositorio local a un repositorio remoto, use el comando git push. Si otro usuario envía cambios al repositorio remoto y desea asegurarse de tener la última versión de lo que hay en el repositorio remoto, use git pull o git fetch.
Para configurar GitHub como un repositorio Git remoto, realice los siguientes pasos:
Figura 4: Creación del repositorio de Git
3. Si desea conectar el repositorio que creó en el primer artículo, haga clic en «Importar repositorio» en la parte superior.
4. Una vez que haya creado el repositorio, busque la URL de clonación de HTTPS haciendo clic en el botón «Código». Haga clic en el botón copiar para copiar la URL (figura 5).
Figura 5: Copiar la URL del repositorio
5. En su estación de trabajo, ahora puede clonar el nuevo repositorio. en mi caso seria
clon de git https://github.com/andy-schneider/gitDemo.git
6. Es posible que se le soliciten las credenciales de Github cuando clone el repositorio. Esto solo sucederá la primera vez. Una vez que las credenciales se almacenan en caché, puede usar git pull y git push sin indicaciones.
7. ¡Felicitaciones, ahora tiene un repositorio git en GitHub!
Trabajando con otros
Para colaborar con otras personas en una base de código, es importante evitar cambios conflictivos. Mejorar el proceso que usamos anteriormente, junto con la estructura de archivos del propio repositorio, puede ayudar a evitar cambios conflictivos. No los eliminará, pero puede ayudar dramáticamente. Hay dos nuevos conceptos que deben entenderse para colaborar con otros con éxito: una rama y una solicitud de extracción.
Sucursales
Las ramas son una forma de nombrar un conjunto de cambios en un repositorio de git. Hasta ahora, hemos estado haciendo cambios en la rama «principal», comprometiéndolos y empujándolos. Para trabajar correctamente con otros, ese flujo de trabajo debe actualizarse.
Antes de comenzar a editar el código, cree una rama. Esto le permite realizar fácilmente un seguimiento del cambio en el que está trabajando.
1. Cree una rama usando el comando de rama.
git branch MyFirstFeature
2. Para cambiar a esa sucursal, debe comprobarlo.
git checkout MyFirstFeature
3. Usando el estado de git, puede ver en qué rama se encuentra.
git status
> En la rama MyFirstFeature
> nada que cometer, árbol de trabajo limpio
4. Cree un archivo con contenido nuevo.
Add-Content "File1.txt" -value "This is the first feature"
5. Organice los cambios y confírmelos al repositorio local.
git add . git commit -m “My first feature”
El objetivo a partir de aquí es llevar nuestros cambios a la rama principal en el servidor Git (GitHub) para que otros colaboradores tengan acceso a esta gran característica nueva.
Lo primero que debe hacer es enviar esta rama y todas sus actualizaciones al repositorio en GitHub. Si intenta hacer un git push, recibirá un mensaje de error.
empujar git
fatal: la rama actual MyFirstFeature no tiene una rama ascendente.
Para empujar la rama actual y configurar el control remoto como ascendente, use
git push --set-upstream origin MyFirstFeature
Para que esto suceda automáticamente para las sucursales sin un seguimiento ascendente, consulte ‘push.autoSetupRemote’ en ‘git help config’.
Lo que esto dice es que el repositorio remoto no conoce la rama MyFirstFeature. Sin embargo, ¡te dice cómo solucionarlo! Correr
git push –set upstream origin MyFirstFeature
Ese comando le dijo a Git con qué rama sincronizar en GitHub cuando se producen cambios en su rama MyFirstFeature local. ¡Ahora tu código está en GitHub! Sin embargo, el trabajo no está del todo hecho. El siguiente paso es fusionar su código en la rama principal para que pueda implementarse y otros desarrolladores puedan extraer el código fácilmente.
Para fusionar esta rama con la principal, se debe enviar una solicitud de extracción. Una solicitud de extracción parece un nombre extraño para tal operación. ¿Recuerdas la diferencia entre jalar y empujar? Estas operaciones son relativas a la rama principal en el repositorio remoto. Cuando envía una solicitud de extracción, está solicitando que su rama sea extraída de la rama principal.
Cuando haya enviado sus cambios, debería haber visto un mensaje sobre cómo crear una solicitud de extracción. La URL que me dio fue https://github.com/andy-schneider/gitDemo/pull/new/MyFirstFeature.
Si busca la URL que GitHub le proporcionó cuando impulsó su rama, debería poder enviar y completar la solicitud de incorporación de cambios. Primero, cree la solicitud de extracción, como se ve en la Figura 6.
Figura 6: Creación de la solicitud de extracción
Una vez que cree la solicitud de extracción, podrá fusionarla. Tenga en cuenta que muestra que desea fusionar la rama MyFirstFeature en la rama principal (Figura 7). También me muestra que no hay conflictos, por lo que esta combinación puede ocurrir automáticamente.
Figura 7: Fusión de la rama MyFirstFeature en la rama principal
Puede completar la combinación.
El uso de una solicitud de extracción (o PR) en su flujo de trabajo con otros compañeros de equipo también puede proporcionar otros beneficios. Hay una oportunidad para revisiones de código. Puede configurar reglas para que la persona que envió un PR no pueda completarlo. Alguien más tendría que revisar el cambio y aprobar la fusión con la principal.
Si la persona que revisa el PR tiene sugerencias para el colaborador, los desarrolladores pueden continuar realizando cambios en la rama MyFirstFeture y enviarlo a GitHub. Cuando el revisor está satisfecho, se puede aceptar la combinación.
Hazlo
En este artículo, analizamos las capacidades y procesos de Git para colaborar fácilmente con compañeros de equipo en una base de código. El próximo artículo de la serie se centrará en cómo integrar los flujos de trabajo de Git directamente en VS Code y algunas técnicas avanzadas en Git. Si no ha comenzado a usar el control de código fuente, ¡ahora es el momento perfecto para comenzar!
