Lineamientos de Repositorio

 Usar correo de la empresa, nombre y foto de perfil

 Antes de empezar a trabajar en tu código después del último commit, haz
un fetch o un pull para traerte los cambios del remoto y traer lo último que
hayan hecho tus compañeros.
 Commits obligatorios antes de salir a comer y al salir de la oficina. Sin embargo,
se puede hacer tantos commits como deseen durante todo el día.
o Revisar si con Push
 Formato de comentarios en los Commits:
o Titulo Corto + ID de requerimiento o issue relacionado en caso que tenga
ID.
o Etiquetas:
 Change: Cuando cambia una funcionalidad existente
 NewFeature: Para funcionalidades nuevas.
 Fixed: Para corrección de errores
 Advance (X%): Para indicar el avance, se usar en conjunto con
otras etiquetas
 Removed: para indicar que se eliminó
 Security: para temas de seguridad y vulnerabilidades
 docs: Se realizaron cambios en la documentacion.
 style: Se aplico formato, comas y puntos faltantes, etc; Sin
cambios en el codigo.
 refactor: Refactorizacion del codigo en produccion.
 test: Se añadieron pruebas, refactorizacion de pruebas; Sin
cambios en el codigo.
 chore: Actualizacion de tareas de build, configuracion del admin.
de paquetes; Sin cambios en el codigo.

o Redactar los cambios y el por qué.
 REVISAR: No hacer push directamente al master
o Cada característica o bug debería trabajarse en su propia rama, y es ahí
en dónde se deberían recibir todos los push. Estas ramas deberían salir a
su vez de la rama de desarrollo, así que una vez terminado el trabajo en
cuestión, la rama debería mezclarse con la de desarrollo.
o Solo el código definitivo, bien probado y revisado debería ir al master, y
para ello debería ser necesario un Pull Request que alguien deba aprobar.
¿Bitbucket, por defecto ya lo tienen configurado?
 ¿Usamos alguna metodología de gestión de ramas como Git-Flow?
 ¿Tenemos reglas como estas?
 o
 Versionar Bases de Datos y otras cosas necesarias.
o Su esquema en formato instrucciones SQL para poder reconstruirla en
cualquier momento y conocer su evolución en el tiempo.
o Cada vez que se realice un cambio sobre la base de datos puedes generar
su esquema a un archivo de texto y archivarlo con el resto del código
fuente. Puedes hacerlo con alguna herramienta especializada que lo
automatice o puedes hacerlo a mano. Pero hazlo.
 Excluirás cosas del control de código
o hay muchas cosas que no deberían estar bajo control de código fuente: tus
ajustes personales en el editor de código que utilices, los archivos
auxiliares que solo utilizas tú, resultados de las compilaciones (las famosas
carpetas "bin" y "obj" por ejemplo), dependencias (carpetas
"node_modules", "packages" y similares), etc...
o Para algo se inventó el archivo .gitignore en Git o la
propiedad svn:ignore en Subversion, por citar los más conocidos. Mete
ahí los archivos y carpetas (o plantillas de archivos y carpetas) a excluir
del control de código, y asegúrate que no incluyes cosas molestas o
contingentes.

Tenemos un chagelog?

Versiones del Sistema:

 Versiones mayores: 1.0, 2.0, etc.
 Versiones menores: 1.1, 1.2, 1.3, etc.
 Versiones de emergencia: 1.1.1, 1.1.2, etc.