En este hito 0 del proyecto se trata de poner a punto las herramientas que se van a usar para comunicar los objetivos, los ejercicios y las prácticas durante el resto del curso. Durante el mismo, se busca también que se interioricen una serie de buenas prácticas a la hora de trabajar con repositorios de git. Para ello, se creará un repositorio que se usará durante el resto de la asignatura para mostrar el avance el proyecto de despliegue de una aplicación en diferentes hitos. El repositorio contendrá
No estamos recomendando que se use ninguno de ellos. De hecho, preferimos que no se haga. En todo caso, eso es tema para el siguiente hito.
Licencia que se va a usar en el proyecto.
Otra serie de ficheros de uso habitual en repositorios.
Haber rellenado en la hoja de cálculo correspondiente la equivalencia entre nombre real y nick en GitHub (que se ha compartido con la lista de correo en Google Drive, es decir, tendrás que estar dado de alta en la lista de correo para cumplir este primer requisito) y haber cumplimentado los objetivos de la primera sesión.
Primero, hay que configurar correctamente el entorno, lo que incluye * Creación de par de claves y subida de clave a GitHub * Configuración correcta del nombre y correo electrónico para que aparezca en los commits. * Edición del perfil para que aparezca nombre completo y ciudad, así como universidad.
Usar un repositorio de forma correcta no sólo permite organizar el trabajo de forma más eficiente, sino que también contribuye a que sea más fácil colaborar con él y a la creación de buenos hábitos de trabajo colaborativo. Hay una serie de buenas prácticas, que incluyen, pero no se limitan, a
Usar o bien el sistema de control de versiones que se incluya en el entorno de desarrollo, y con esto quiero decir, por ejemplo, que si se suele usar Emacs o NetBeans, suelen tener un sistema de control de versiones integrado, o bien la línea de órdenes, lo que se recomienda. No usar nunca el interfaz gráfico de GitHub ni, salvo en caso de urgencia (considerándose como tal que tengas que hacer algo urgentemente y no tengas acceso a tu propio ordenador, sino sólo a un navegador y recuerdes tu contraseña de GitHub (no es que estemos recomendando meter contraseñas de nada en ordenadores ajenos (vale, ya paro. Que no lo hagáis y ya está))), editar usando el editor de GitHub.
Trabajar siempre con hitos (milestones) y órdenes de trabajo (issues) en el repositorio. En este caso, el hito será la entrega de la práctica y las órdenes de trabajo las diferentes tareas necesarias para terminar el hito.
Hacer commits que abarquen una sola funcionalidad o tarea, pero sólo si la funcionalidad es correcta (no tiene errores sintácticos, por ejemplo). Hacer commits a menudo.
Todo commit debe corresponder a una tarea que se haya establecido
en el repositorio, toda tarea se cierra con un commit (simplemente
incluyendo closes #[tarea], por ejemplo closes #1 si es el
primer issue o tarea. Para referenciar una tarea, simplemente se
pone el número de la tarea, por ejemplo
Avanza la tarea #1
No incluir en el repositorio ningún fichero que pueda ser generado a
partir del mismo, incluir un procedimiento para generar tales
ficheros. Por ejemplo, ningún fichero compilado a partir de otros, o
un PDF generado a partir de los ficheros LaTeX, o los ficheros
generados por los entornos virtuales de ciertos lenguajes. Esos
ficheros, además, se tendrán que incluir en .gitignore para que no
aparezcan como “no seguidos” cuando se haga git status.
No incluir en el repositorio ningún código que no sea propio, incluir en el mismo el procedimiento para incluir ese código en la compilación, generalmente en forma de fichero de requisitos. Si el código sobre el que se va a trabajar es directamente de otro repositorio, hacer un fork del mismo, no copiar los ficheros. La estructura de un repositorio siempre tiene que respetarse, y la mejor forma de atribuir correctamente los cambios es trabajar sobre el repositorio original modificado.
Usar desde el principio un fichero .gitignore para evitar añadir
accidentalmente ficheros que no deban estar en el repositorio, como
ficheros de respaldo o ficheros generados en compilación o
construcción.
No incluir ficheros binarios en el repositorio, aunque se necesiten en el proyecto. Para ello están los releases.
Si se va a usar algún proyecto anterior, hacer un fork del mismo, no copiar los ficheros y subirlos como contribución propia. Las contribuciones, siempre que sea posible, deben estar firmadas por la persona que las haya creado.
Siempre comprobar, antes de hacer un pull request, que se está trabajando sobre la última copia del fichero para evitar conflictos que imposibiliten que se lleve a cabo la fusión por parte de la persona encargada del mismo.
Subir los fuentes a GitHub y añadir al fichero de entrega del proyecto el nombre del proyecto, el autor y un enlace al mismo y hacer un pull request.
Cada proyecto tendrá su propio repositorio en GitHub. La documentación se incluirá en ficheros Markdown, Textile o algún otro lenguaje de marcas. Esta descripción de la aplicación irá evolucionando con los diferentes hitos.
Si se quiere incluir
material adicional externo al proyecto, pero que puede ser útil para
complementar la entrega de la práctica, por ejemplo capturas de
pantalla de la configuración de git o del par clave pública/privada, se aconseja que se haga una
rama con el nombre del hito, por ejemplo hito0 y se indique en la
entrega de la práctica con un enlace a la misma. También esta
documentación externa puede ir a la rama gh-pages, si se aprende como usarla correctamente.
2 puntos: Puntos adicionales por avance adicional en el proyecto, ayuda a los compañeros pública, o punto de originalidad, perfil de GitHub con todos los elementos necesarios, página del repositorio en GitHub Pages.
Si el repositorio no existe, el alumno no ha rellenado su nick de GitHub en el repositorio compartido, no tiene la licencia de software libre correcta, tiene algún error, no se ha hecho pull request correctamente o no están los fuentes publicados, la práctica estará suspensa.