Todos sabemos que Git es uno de los controles de versiones más populares utilizados por los desarrolladores de todo el mundo. Los desarrolladores lo usan desde hace muchos años, pero no todos los desarrolladores conocen las mejores prácticas para usarlo.
Hay varias formas de usar git para comunicarse con su equipo. Puede usar estas mejores prácticas de git de un pequeño equipo de dos a diez desarrolladores. Cuando trabaje con git, puede considerar las siguientes algunas de las mejores prácticas que se detallan a continuación…
1. Se supone que las confirmaciones son pequeñas y frecuentes
Cada vez que haya realizado una única alteración lógica, puede confirmar el código. La confirmación frecuente lo ayuda a escribir mensajes de confirmación breves que son breves pero informativos. Además, proporcionará un significado significativo para aquellos que puedan estar leyendo su código.
Cometer cosas pequeñas también hace que los fallos u otros problemas graves sean mucho más fáciles de manejar. A continuación se presentan algunas señales que normalmente significan que no contribuyes lo suficiente…
- Por primera vez, un archivo de más de 100 líneas es una sola confirmación.
- Modificas más de 50 líneas de un archivo en una sola confirmación.
2. Los mensajes de compromiso deben ser semánticos
Cada mensaje de confirmación debe tener una explicación de por qué necesita actualizar el código en primer lugar o qué se ha modificado, en el nivel de detalle requerido.
Cuando alguien pregunta si se ha creado o actualizado una línea de código, el mensaje de confirmación debe ser transparente. Aquí hay algunas señales de código que indican que ha estado escribiendo un mensaje de confirmación débil:
- El mensaje de confirmación tiene menos de tres palabras.
- Su mensaje de confirmación es de demasiado alto nivel
3. Uso de Sucursales
Cuando realiza varias confirmaciones que están conectadas, pertenecen a una rama diferente. Una de las cosas más llamativas de las ramas de git son las requests de extracción, lo que facilita abordar una lista de confirmaciones antes de volver a fusionarse con la rama principal de git.
El uso de ramas hace que la fusión con la rama principal de git suene significativa. Le da la oportunidad de ver todas las mejoras finales mientras ve las confirmaciones de trabajo en progreso. Eso también asegura que la rama principal todavía esté lista para lanzarse, sin código roto.
Mientras trabaja en una rama de git, asegúrese de ejecutar git pull regularmente. Por lo tanto, su sucursal no se queda atrás y reduce la probabilidad de conflictos de fusión.
4. Una sucursal, una característica
El concepto de rama característica es que toda la funcionalidad nueva debe estar en una rama dedicada separada en lugar de la rama principal. Esta práctica asegura que la rama principal nunca pueda tener código sin terminar, lo que es un beneficio significativo para los entornos de integración continua.
Entonces puede usar una nueva rama para una nueva función. Una vez que complete su trabajo, haga una solicitud de extracción y git merge cambios en la rama principal. Puede crear una nueva rama de funciones para la siguiente función y repetir el proceso.
Con una rama, una estrategia de funciones, logrará muchas cosas buenas.
- Una revisión del código será fácil ya que solo se trata de una función.
- Te mantienes enfocado y productivo mientras haces una cosa a la vez.
- Ayuda a otro desarrollador a comprender el código debido a pequeños cambios.
5. Manejar la combinación correctamente
Cada miembro del equipo debe trabajar en una rama de función diferente. Pero a pesar de que otras ramas están en uso, todas inevitablemente cambian archivos similares específicos. Al combinar las modificaciones con la rama principal, la fusión no suele ser instantánea. Podría ser necesaria la interacción humana para resolver los cambios de los dos escritores en el mismo archivo.
Hay muchas funciones y comandos de Git que admiten los conflictos de combinación de Git en los nuevos editores modernos. Muestran las diferentes opciones para combinar cada sección del archivo. Podría ser el momento de usar un nuevo editor de código si no es compatible con esas capacidades.
6. Repositorio Único
Los equipos grandes pueden beneficiarse de varios repositorios de proyectos, bibliotecas, etc. Para los equipos de menos de 10 años, generalmente nos gusta conservar todo el código necesario para ejecutar todo el producto en un solo repositorio.
Esto permite que el programa se maneje en su totalidad y se distribuya como una sola entidad. Las aplicaciones internas que se reutilizan entre proyectos deben estar disponibles a través de un administrador de paquetes, etc.
Hay muchas ventajas para un equipo pequeño al usar el repositorio único:
- Su código permanecerá sincronizado
- La refactorización se vuelve barata
Es posible que necesite varios repositorios para su producto; Aquí hay algunas razones.
- Suponga que su producto no es completamente de código abierto. Es posible que deba mantener algunos códigos/bibliotecas en repositorios separados.
- De manera similar, si su producto tiene algún trabajo de cliente, entonces debería ir a un repositorio separado.
7. Evite comprometer dependencias en Repo
Su repositorio de Git es donde realiza un seguimiento de su código fuente. No es una buena práctica mantener dependencias. Además, enviar sus dependencias aumentará considerablemente el tamaño del repositorio del proyecto.
- Use una herramienta de compilación/dependencia adecuada en lugar de Git.
- Hay uno para (casi) todas las pilas de software que existen.
- como Maven para Java
- Npm para aplicaciones Node.js
8. No cometer código roto
¿Sabes qué es lo más atroz que puede hacer un desarrollador? Pueden bloquear a otros desarrolladores de su trabajo (con su código roto). Si está ansioso por hacer una confirmación de git, asegúrese de probar su código antes de confirmar. Puede usar el comando Stash de Git si necesita cambiar su rama para trabajar en otra cosa. Pero nunca verifique el código roto.
9. Usa etiquetas
Usted y su equipo pueden usar etiquetas cuando liberan el código. Aunque una rama acumula un historial de modificaciones relacionadas con las confirmaciones, la etiqueta es una instantánea del estado de la rama en ese momento.
Una etiqueta es como una rama estable . A diferencia de las ramas, las etiquetas no tienen un historial de confirmaciones adicional después de formarse. Hay muchas ventajas en el uso de etiquetas con su lanzamiento.
- Le permite realizar un seguimiento del número de versión de su proyecto.
- Además, te ayuda a comparar las modificaciones entre las dos versiones diferentes.
- Le permite registrar las notas de lanzamiento de su proyecto, que son valiosas para su equipo y las partes interesadas.
Espero que estas mejores prácticas de Git para equipos pequeños lo ayuden a usar Git de manera efectiva en su grupo. Git es una herramienta avanzada que lleva tiempo aprender. Usando estas prácticas, usted y sus equipos trabajan de manera efectiva usando Git.