Confirma con regularidad (Commit)
Recomendado
Subir al repositorio de origen (push) de manera regular hace que las unificaciones con el código existente sean pequeñas. Esto permite compartir el código con más frecuencia con otros compañeros del equipo, siendo más fácil para todos integrar los cambios regularmente y evitando tener conflictos al fusionar cambios y ramas.
Confirmaciones relacionadas con cambios
Recomendado
Un commit debe ser un contenedor para los cambios relacionados. Por ejemplo, corregir dos errores diferentes debería producir dos confirmaciones separadas. Los pequeños commits facilitan que otros miembros del equipo entiendan los cambios y los restituyan si algo sale mal.
No confirmes trabajos a medio hacer
Recomendado
Solo debes confirmar código cuando se complete. Esto no significa que tenga que completar una característica grande y completa antes de confirmarse. Lo ideal es dividir la implementación de la característica en partes lógicas y más manejables, que puedas confirmar y subir al repositorio de forma independiente y con más frecuencia.
Escribe mensajes de confirmación útiles
Recomendado
Crear mensajes de confirmación intuitivos y descriptivos es una de las mejores prácticas que puedes realizar, sobre todo para otras personas que utilicen el repositorio.
Permite a los integrantes de nuestro equipo (y a otras personas que puedan usar el repositorio) comprender rápidamente los cambios sin tener que leer el código.
También es importante crear mensajes de confirmación de calidad para poder responder algunas preguntas cuando revisamos el historial de revisiones.
GIT establece una regla general donde indica que una buena longitud del mensaje, y así proporcionar un resumen corto de la confirmación, sería utilizar entre 50 y 72 caracteres. Esta longitud tiene mucha relación con el comando git log --oneline que lista todas la confirmaciones realizadas hasta el momento en el repositorio.
No hagas push de elementos que no funcionan en tu local
Recomendado
Además de no subir partes incompletas, no hagas push a elementos que no funcionan, ya que esto romperá el flujo de Integración Continua para todos los compañeros. Espera a que esté solucionado. El control de versiones no es un sistema de backup.
Utiliza Ramas (Branch)
Recomendado
La ramificación es una de las características más poderosas de Git, y esto no es por accidente: la ramificación rápida y fácil fue un requisito central desde el primer día.
Las ramas son la herramienta perfecta para ayudar a evitar mezclar diferentes líneas de desarrollo. Debes usar ramas constantemente en tus flujos de trabajo de desarrollo: para nuevas funciones, correcciones de errores, experimentos, ideas, etc.
Git permite elegir entre una gran cantidad de flujos de trabajo diferentes: ramas de larga duración, ramas temáticas, de fusión o de reajuste, etc.
El que se elija un flujo de trabajo frente a otro depende de una serie de factores: el entorno, la tecnología, los procesos de desarrollo e implementación general y las preferencias personales y de los compañeros. Independientemente de cómo elijas trabajar, solo asegúrate de acordar un flujo de trabajo común al equipo de desarrollo para que todos sigan dicho flujo.
Puedes echarle un vistazo a los siguientes flujos:
- "GitFlow"
- "GitHub FLow" (Una simplificación de GitFlow)
- "Gitlab Flow" (Que se podría considerar una extensión de GitHub Flow)
Aunque todas estas estrategias han tenido éxito, no funcionan en todos los entornos. La elección de una estrategia equivocada puede lastrar la eficiencia y productividad del equipo.
Recuerda borrar ramas innecesarias
Recomendado
Una vez que el desarrollo sobre una rama ha finalizado, se deberán volcar los cambios a una rama principal. Las ramas utilizadas para el desarrollo de características, experimentos, etc, no son necesarias mantenerlas y se pueden borrar una vez que se hayan integrado los cambios. Existen herramientas que automatizan el control del flujo y te permiten liberarte de ese trabajo. Busca la que mejor se adapte.
Actualiza tu repositorio antes de enviar cambios (Pull y Push)
Recomendado
Es común que mientras se trabaja en el repositorio local, otro compañero haya realizado algún cambio (confirmación o commit) en el repositorio remoto.
Por tanto, para mantener la integridad de todo el proyecto, antes de enviar cualquier cambio al repositorio remoto (git push), se debe ‘extraer’ las últimas confirmaciones del repositorio remoto en nuestro repositorio local (git pull).
No subir ficheros innecesarios al repositorio
Recomendado
Los repositorios a veces acostumbran a almacenar todo tipo de ficheros, simplemente porque estaban allí. Trata de almacenar solo activos que se puedan gestionar a través de aplicaciones de desarrollo (o IDEs) evitando archivos que no son legibles en modo texto con facilidad, como documentación, imágenes, librerías, etc.
Para conseguir esto, puedes utilizar gitignore
Divide el trabajo en repositorios
Recomendado
Diferentes trabajos por repositorio
Aprende a separar cada trabajo diferenciado en distintos repositorios. Separar los distintos tipos de trabajo previamente a su desarrollo permite ahorrar mucho tiempo en el futuro.
Control de acceso en cada repositorio
Si alguien tiene acceso a un repositorio, tiene acceso a todo el repositorio, todas las ramas, historial, etc. Si necesita controlar el acceso de los diferentes miembros, separe los trabajos en diferentes repositorios.
Repositorios separados para archivos necesarios en múltiples proyectos
Esto promueve el uso compartido y la reutilización del código, y es muy recomendable.
Repositorios separados para archivos grandes
Git no maneja archivos grandes de manera ideal y los repositorios con archivos grandes pueden ser lentos. Si debe confirmarlos, separarlos en su propio repositorio puede hacer que los desarrollos sean más eficientes.