Programming Style Guide

Guía de Estilo y Flujo de Trabajo en GitHub

1. Reglas generales de Git

Clonar el repositorio:

git clone <URL_DEL_REPO>

Ver las ramas disponibles en el repositorio remoto:

git branch -r

Obtener y actualizar las ramas remotas en el repositorio local:

git fetch --all

Para cada cambio, crear una nueva rama descriptiva (Ejemplo: agregando-entidad-cliente, actualizando-controlador-libro)

git checkout -b nombre-de-la-rama

Realizar cambios, probar y hacer commits con mensajes claros

git add . git commit -m "Descripción clara del cambio"

Subir la rama al repositorio remoto:

git push origin nombre-de-la-rama

Hacer Pull Request a la rama dev

Revisar y aprobar los cambios antes de fusionar con dev

Solo versiones funcionales van a main

Actualizar la rama local con los últimos cambios antes de trabajar:

git pull origin dev

2. Estructura de ramas en el repositorio

main: Solo versiones estables y funcionales. No se toca directamente.

dev: Aquí se prueban los cambios antes de ir a main.

Para cada nueva funcionalidad o corrección, se crea una rama desde dev, se prueba y luego se hace un Pull Request a dev.

3. Convenciones de nombres y código

3.1 Nombres de Ramas

Usar nombres descriptivos en minúsculas y separados por guiones.

Ejemplo: agregando-entidad-cliente, corrigiendo-bug-login

3.2 Estilo de Código

Formato:

Seguir el estándar Google Java Style

Usar sangría de 4 espacios, no tabs.

Nombres de Clases: PascalCase (ClienteService, LibroController)

Nombres de Métodos y Variables: camelCase (calcularPrecio, nombreCliente)

Constantes: UPPER_CASE (TASA_INTERES, MAX_USUARIOS)

Evitar nombres genéricos (datos, variable1), usar nombres descriptivos.

3.3 Comentarios y Commits

Comentar el código de manera clara y útil.

// Método para calcular el precio con IVA public double calcularPrecio(double precio) { return precio * 1.19; }

Mensajes de commit deben ser específicos

git commit -m "Agregada validación en el controlador de usuario"

4. Buenas prácticas generales

Probar los cambios antes de hacer un Pull Request.

Actualizar la rama dev antes de comenzar una nueva funcionalidad.

git checkout dev git pull origin dev

Si el código afecta las vistas, actualizarlas también.

Revisar y aprobar los Pull Requests antes de fusionar con dev.

Evitar mezclar múltiples cambios en un solo commit.

Eliminar ramas locales después de fusionarlas para mantener el repositorio limpio:

git branch -d nombre-de-la-rama

Si una rama eliminada sigue apareciendo en remoto, eliminarla con:

git push origin --delete nombre-de-la-rama

Siguiendo estas reglas, mantendremos un código limpio, estructurado y un flujo de trabajo organizado en GitHub. 🚀