Comprender Git para desarrolladores en 2024

Ahora que has aprendido los conceptos básicos de Git en la publicación anterior, en Git para principiantes te ayudaremos a elevar tu nivel al nivel avanzado. En esta continuación del blog anterior, descubrimos el flujo de trabajo de Git y algunas de sus operaciones clave. Como es habitual, podemos comenzar con un estudio de caso. Usted es un gerente de proyecto que utiliza Git como VCS y recibe un requisito de un cliente para desarrollar dos nuevas características para el proyecto. Has creado dos equipos para gestionar cada función mientras planificas todo. Por ejemplo, el equipo A tardará dos semanas en completar el proyecto, mientras que el equipo B tardará tres semanas en completar y desarrollar funciones. Más sobre las ramas de Git Para hacer frente a este tipo de situaciones, Git utiliza ramas. Aquí hay una representación de la rama git, según nuestros requisitos; Como puedes ver en la figura de arriba, tiene una línea central que representa la rama principal del establo (aquí llamada maestra). Por lo general, esta rama entra en producción y es accesible para los usuarios. Debe prestar atención a la rama Main o Master, ya que contiene la versión con menos errores y cualquier versión de esta rama debe realizarse con cuidado y con las pruebas adecuadas. Ahora, justo encima de la rama principal (en la foto), podemos ver la rama Característica A, que fue desarrollada por el Equipo A. Los círculos indican los nuevos cambios realizados por el Equipo A para implementar la Característica A. Como puede ver, estos cambios no será visible en la rama maestra. De manera similar, en la rama Master, podemos ver la rama Característica B que contiene el código del Equipo B para la Característica B y no es visible para el Equipo A y la rama Master. Beneficios Aislamiento y desarrollo paralelo Como en el ejemplo anterior, el Equipo A y el Equipo B pueden desarrollar características de forma independiente, sin confusión con respecto a los cambios de código, ya que ambos códigos están aislados entre ramas. Pruebas eficientes y garantía de calidad Cuando las funciones están completas, el equipo de control de calidad también puede probarlas por separado, ya que una rama no tiene relación con la otra función. Gestión de versiones y lanzamientos Una vez que las funciones estén completas, puede fusionar la rama nuevamente con la rama principal, es decir, después de todas las pruebas y control de calidad, podemos lanzarla a los usuarios. Puedes hacer esto fácilmente usando ramas de git. Riesgo reducido de romper el código central. Si hay un problema con una de las características (como incompatibilidad del sistema o incompatibilidad con cualquier funcionalidad esencial anterior del proyecto), simplemente puede eliminar esta rama ya que el desarrollo es independiente de la versión estable. garantizará el código de seguridad. Para llevar: Git Branching significa abandonar la línea principal de desarrollo y continuar trabajando por separado sin afectar la base del código principal. Ventajas: Aislar cambios Cada rama representa una línea de desarrollo separada. Puede trabajar en funciones, correcciones de errores o experimentos sin afectar la rama principal. Desarrollo paralelo: varios miembros del equipo pueden trabajar en diferentes ramas al mismo tiempo. Pruebas y experimentación: cree ramas para probar cambios o probar nuevas ideas sin afectar la base del código estable. Gestión de versiones y lanzamientos: las ramas le permiten mantener diferentes versiones de su proyecto. Riesgo reducido de romper el código central: al trabajar en sucursales, los desarrolladores minimizan el riesgo de introducir errores. Utilice el siguiente comando para crear una nueva rama de git: $ git branch Crea una nueva sucursal con el nombre que le des. Después de crear una nueva rama, puedes editarla con el comando anterior. $git pago Alternativamente, puede crear y cambiar a una rama especificando $ git checkout –b Utilice el siguiente comando para enumerar todas las ramas en el repositorio de git: $ git rama o git rama –list Para eliminar una rama, puede utilizar: $ git rama -d Git Checkout A medida que avanza el proyecto, debes verificar y verificar las características desarrolladas por tus equipos (ya que eres el líder del equipo). En el caso de git, todo el repositorio estará a tu disposición (ya que git es un sistema de control de versiones distribuido). Git checkout facilita el cambio entre ramas y versiones. Uno de los aspectos relevantes de git checkout es Head, Head es la versión que usted verifica. Cuando estás en la rama master, head es por defecto la última versión (o confirmación) de la rama master. Además, a veces surge una situación en la que el líder no es el último compromiso de la rama. Esta situación se conoce como cabeza desprendida. La cabeza desprendida suele ocurrir cuando comprobamos cualquier otra versión. Git Merge A medida que pasa el tiempo, el control de calidad finalmente completa y prueba la característica A. Ahora puedes publicarlo en la versión estable del proyecto. Con la ayuda de Git Merge, puedes implementarlo sin esfuerzo. Usando Git merge, puedes combinar cambios de dos o más ramas en una sola rama. Como se muestra en la imagen de arriba, la característica A se fusiona en la rama maestra y se crea una confirmación (o versión) en la rama maestra. Todos los cambios en la rama Característica A se migran o fusionan en la rama principal. Tipos de combinación en Git Hay dos tipos básicos de combinación en Git. Fusión de avance rápido Esto ocurre cuando la punta de la rama actual es un antepasado directo de la rama de destino. Puede consultar la imagen de arriba, que es un ejemplo clásico de combinación rápida. Fusión de tres vías Este tipo de fusión ocurre cuando cambia la rama base. Git crea una nueva confirmación de fusión con cambios de ambas ramas. Utilizando el proceso de fusión de tres vías, Git compara los cambios en ambas ramas de acuerdo con la rama base. En nuestro caso, la característica A se compara con la rama maestra y todos los cambios se incorporan a la rama maestra mediante la creación de una nueva confirmación en la rama maestra. Resolución de conflictos de fusión Normalmente, los conflictos de fusión se producen cuando se intenta fusionar dos ramas separadas que contienen cambios diferentes en las mismas ubicaciones, dentro del mismo archivo. Permítanme explicarles con nuestro ejemplo que después de desarrollar y lanzar una función, generalmente se agrega a los documentos de lanzamiento del proyecto. Por lo tanto, después de desarrollar la característica A, el equipo A actualizará sus documentos de lanzamiento una vez que se fusionen con la rama principal. Supongamos que es el quinto punto del documento de lanzamiento, este cambio no estará presente en la rama de la Característica B. Lo mismo se hará después de que el Equipo B complete la Característica B, pero al agregar las notas de la versión, será el quinto punto del lanzamiento. (ya que las notas de la Característica A no están presentes en la rama de la Característica B). Ahora, al fusionar la rama habrá un conflicto para git, en la rama principal la nota de la versión de la característica A es el quinto punto, pero según la característica B el quinto punto es su nota de la versión. Esto se llama conflicto de fusión. Cuando surge un conflicto de fusión, debemos decidir cómo realizar cambios. En el caso anterior, podemos eliminar la Característica B como sexto punto y agregar el cambio al proyecto. Una vez resuelto el conflicto, se crea una nueva confirmación. Git Rebase es otra herramienta más para migrar cambios de una rama a otra. Rebasar implica tomar una rama y agregarla a la punta de otra rama. A diferencia de la fusión, que crea una confirmación de fusión para combinar cambios, la rebase funciona moviendo o «reproduciendo» las confirmaciones de una rama a otra, reescribiendo efectivamente el historial de confirmaciones. La figura muestra el resultado después de cambiar el nombre de la rama Característica B a la rama maestra. Pasos involucrados en rebase Elija la rama base: comience seleccionando la rama que desea rebase Inicie la rebase: con la rama base marcada, inicie el comando rebase $ git rebase Git identifica confirmaciones divergentes: identifica confirmaciones exclusivas de la rama de origen que deben aplicarse a la rama base. Las confirmaciones se «reproducen», lo que significa que git realiza los mismos cambios. Resolver conflictos (si los hay): resuelva los conflictos en cada archivo afectado, márquelos como resueltos y continúe con el proceso de rebase. Completar la rebase: una vez que todas las confirmaciones se hayan aplicado correctamente, Git completa la rebase. El HEAD de la rama base se actualiza para señalar la confirmación más reciente que se acaba de reproducir. Beneficios de Rebase Cleaner History: Rebase crea un historial de confirmaciones más limpio que la fusión. Integración con sucursales remotas: utilice el cambio de base para garantizar que sus confirmaciones se apliquen limpiamente en una sucursal remota (por ejemplo, al contribuir a un proyecto externo). Coherencia de la instantánea: la instantánea final después del cambio de base es la misma que la que se obtiene después de la fusión; Sólo la historia es diferente. Git Cherry Pick Este comando le permite aplicar confirmaciones de forma selectiva de una rama a otra. Este escenario suele surgir cuando desea tomar una revisión de una rama o adoptar mejoras en la funcionalidad común (como una nueva estructura de datos desarrollada internamente). Si bien git cherry-pick es útil, no siempre es la mejor práctica. En muchos casos, se prefieren las piezas fundidas tradicionales. La confirmación de la rama de función A ahora se selecciona en la rama de función B (la que se muestra en color rojo). Puede implementar Cherry-pick ejecutando el siguiente comando $ git cherry-pick Git Tagging Git puede gestionar cambios en su código y es útil para colaborar con otros. Pero, ¿cómo marca versiones específicas de su proyecto para referencia futura? Aquí es donde entra en juego el etiquetado de Git. Piense en las etiquetas de Git como marcadores para el historial de su proyecto. Indican confirmaciones específicas, lo que le permite revisar fácilmente el estado de su código base. Las etiquetas son como etiquetas que proporcionan un nombre claro y fácil de recordar para un punto importante del desarrollo. ¿Por qué etiquetas? Puntos de captura del historial: las etiquetas actúan como instantáneas, congelando un momento específico en la evolución de su código. A diferencia de las ramas, las etiquetas permanecen estáticas y no se ven afectadas por futuras confirmaciones o cambios. Puntos de lanzamiento: la gente suele utilizar etiquetas para marcar lanzamientos importantes (por ejemplo, v1.0, v2.0). Tipos de etiquetas en Git Hay dos tipos principales de etiquetas en Git: Etiquetas ligeras: son referencias simples que apuntan directamente a una confirmación específica. Son livianos porque no almacenan ninguna información adicional. Etiquetas anotadas: son etiquetas más informativas que almacenan datos adicionales, como el nombre del etiquetador, la fecha y un mensaje de etiqueta. Esta información puede ser útil para referencia futura. Para crear una etiqueta ligera: etiqueta $git Utilice el siguiente comando para crear una etiqueta anotada mediante un mensaje. etiqueta $git -a -m “» Para enumerar todas las etiquetas en su repositorio $ git tag Para eliminar una etiqueta $ git tag -d Recuerde: las etiquetas son inmutables, lo que significa que no puede cambiarlas una vez creadas. Simplemente indican un compromiso específico con la historia. Conclusión En conclusión, las sólidas funciones de ramificación y fusión de Git, junto con la selección, el cambio de base y el etiquetado, le permiten administrar eficientemente su base de código. Al dominar estas técnicas, podrá colaborar sin problemas, realizar un seguimiento del historial del proyecto y mantener una comprensión clara de la evolución de su código. Ya sea que sea un desarrollador experimentado o recién esté comenzando su viaje con Git, el uso efectivo de estas características optimizará sus procesos de desarrollo de aplicaciones web y de aplicaciones móviles para garantizar un entorno de desarrollo colaborativo y bien organizado. Analice sus necesidades de desarrollo de aplicaciones con ThinkPalm y nuestro equipo técnico le ayudará a empezar. Autor Bio Pavan Sunny Thomas es un desarrollador Java Full Stack con experiencia en el desarrollo y mantenimiento de aplicaciones web basadas en Java utilizando Spring Boot, Hibernate, Angular y otras tecnologías. Le apasiona el desarrollo web y le gusta aprender nuevas habilidades y herramientas. Pavan, además, un ávido bloguero, comparte sus ideas y consejos sobre desarrollo web y muestra su cartera de proyectos.

About Francisco

Check Also

Grupos de señales y derechos se oponen a la ley de la UE

En una declaración enérgica, Meredith Whittaker, presidenta de Signal, denunció los últimos intentos de la …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *