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.