Proponer un cambio de código
Nette Framework utiliza Git y GitHub para mantener el código base. La mejor manera de contribuir es confirmar los cambios en tu propio fork y luego hacer un pull request en GitHub. Este documento resume los principales pasos para contribuir con éxito.
Preparación del entorno
Comience con la bifurcación de Nette en GitHub. Configure cuidadosamente su entorno Git local, configure su nombre de usuario y correo electrónico, estas credenciales identificarán sus cambios en el historial de Nette Framework.
Trabajar en su parche
Antes de empezar a trabajar en su parche, cree una nueva rama para sus cambios.
git checkout -b new_branch_name
Usted puede trabajar en su cambio de código.
Si es posible, realice los cambios desde la última versión publicada.
Pruebe sus cambios
Necesitas instalar Nette Tester. La forma más fácil es llamar a composer install en la raíz del repositorio.
Ahora debería ser capaz de ejecutar pruebas con ./vendor/bin/tester en el terminal.
Algunas pruebas pueden fallar debido a la falta de php.ini. Por lo tanto debe llamar al ejecutor con el parámetro -c y
especificar la ruta a php.ini, por ejemplo ./vendor/bin/tester -c ./tests/php.ini.
Después de que pueda ejecutar las pruebas, puede implementar las suyas propias o cambiar el fallo para que coincida con el nuevo comportamiento. Lea más sobre las pruebas con Nette Tester en la página de documentación.
Normas de codificación
Tu código debe seguir los estándares de codificación utilizados en Nette Framework. Es fácil porque hay un comprobador y corrector automático. Se puede instalar a través de Composer a su directorio global elegido:
composer create-project nette/coding-standard /path/to/nette-coding-standard
Ahora debería ser capaz de ejecutar la herramienta en el terminal. Por ejemplo, este comando comprueba y corrige el código en
las carpetas src y tests en el directorio actual:
/path/to/nette-coding-standard/ecs check src tests --config /path/to/nette-coding-standard/coding-standard-php71.yml --fix
Confirmación de los cambios
Después de haber cambiado el código, tienes que confirmar los cambios. Crea más confirmaciones, una para cada paso lógico. Cada commit debe ser utilizable tal cual – sin otros commits. Por lo tanto, las pruebas apropiadas también deben incluirse en el mismo commit.
Por favor, compruebe que su código se ajusta a las reglas:
- El código no genera errores
- Su código no rompe ninguna prueba.
- El cambio de código se ha probado.
- No está realizando cambios inútiles en el espacio en blanco.
El mensaje de confirmación debe seguir el formato Latte: fixed multi template rendering [Closes # 69]
es decir
- un área seguida de dos puntos
- el propósito del commit en el pasado, si es posible, empezar con “añadido”, “corregido”, “refactorizado”, cambiado, eliminado
- eventual enlace al issue tracker
- si la confirmación anula la compatibilidad con versiones anteriores, añada “BC break”.
- puede haber una línea libre después del asunto y una descripción más detallada que incluya enlaces al foro.
Solicitud de los commits
Si estás satisfecho con los cambios y commits de tu código, tienes que empujar tus commits a GitHub.
git push origin new_branch_name
Los cambios se presentan públicamente, sin embargo, usted tiene que proponer sus cambios para la integración en la rama maestra de Nette. Para ello, haga un pull request. Cada pull request tiene un título y una descripción. Por favor, proporcione un título descriptivo. A menudo es similar al nombre de la rama, por ejemplo “Securing signals against CSRF attack”.
La descripción del pull request debe contener información más específica sobre los cambios en el código:
- bug fix? yes/no <!-- #issue numbers, if any -->
- new feature? yes/no
- BC break? yes/no
- doc PR: nette/docs#??? <!-- highly welcome, see https://nette.org/en/writing -->
Por favor, cambie la tabla de información para adaptarse a su pull request. Comentarios a cada elemento de la lista:
- Indica si el pull request añade función o es una corrección de errores.
- Eventualmente hace referencia a un problema relacionado, que se cerrará tras fusionar la pull request.
- Dice si el pull request necesita cambios en la documentación, en caso afirmativo, proporciona referencias a los pull requests apropiados. No tienes que proporcionar el cambio de documentación inmediatamente, sin embargo, el pull request no se fusionará si el cambio de documentación es necesario. El cambio de documentación debe prepararse para la documentación en inglés, las mutaciones en otros idiomas son opcionales.
- Dice si el pull request crea una ruptura de BC. Por favor, considere todo lo que cambie la interfaz pública como una ruptura de BC.
La tabla final podría tener este aspecto:
- bug fix? no
- new feature? yes issue #123
- BC break? no
Reformulando sus cambios
Es muy común recibir comentarios a tus cambios de código. Por favor, intenta seguir los cambios propuestos y reelabora tus commits para ello. Puedes confirmar los cambios propuestos como nuevos commits y luego aplastarlos a los anteriores. Consulta el capítulo Rebase interactivo en GitHub. Después de rebase de sus cambios, la fuerza de empuje de sus cambios a su bifurcación remota, todo se propagará automáticamente a la solicitud de extracción.
