Acceso a GIT¶
Esta sección describe como empezar a usar el repositorio GIT de QGIS. Antes de empezar, necesita tener instalado primero un cliente git en su sistema.
Instalación¶
Instalar git en GNU/Linux¶
Los usuarios de distribuciones basadas en Debian pueden hacer:
sudo apt install git
Instalar git en Windows¶
Los usuarios de Windows pueden usar msys git o usar el cliente git suministrado con cygwin.
Instalar git en OSX¶
El proyecto git tiene una compilación de git descargable. Asegúrese de obtener el paquete compatible con su procesador (probablemente x86_64, solo los primeros Mac con procesador Intel necesitan el paquete i386).
Una vez descargado, abra la imagen del disco y ejecute el instalador.
Nota PPC/fuente
El sitio de git no ofrece compilaciones PPC. Si necesita una, o solo quiere más control sobre la instalación, es necesario que lo compile usted mismo.
Descargue el código fuente de https://git-scm.com/. Descomprímalo y en un terminal cámbiese al directorio donde esté el código fuente y entonces:
make prefix=/usr/local
sudo make prefix=/usr/local install
Si no se necesitan ninguno de los extras, Perl, Python o TclTk (GUI), puede deshabilitarlos antes de ejecutar make:
export NO_PERL=
export NO_TCLTK=
export NO_PYTHON=
Accediendo al repositorio¶
Para clonar la rama QGIS maestra:
git clone git://github.com/qgis/QGIS.git
Verificar una rama¶
Para obtener una rama concreta, por ejemplo, la rama de la versión 2.6.1 debe hacer:
cd QGIS
git fetch
git branch --track origin release-2_6_1
git checkout release-2_6_1
Para obtener la rama principal:
cd QGIS
git checkout master
Nota
En QGIS mantenemos nuestro código más estable en la rama de la versión actual. La rama maestra contiene el código correspondiente a las versiones llamadas “inestables”. Publicaremos de forma periódica una versión a partir de la rama maestra y luego continuaremos con la estabilización y la incorporación de forma selectiva de nuevas funcionalidades a la rama principal.
Lea el archivo INSTALL presente en el código fuente para obtener instrucciones especificas sobre la creación de versiones de desarrollo.
Fuentes de documentación de QGIS¶
Si está interesado en verificar las fuentes de documentación de QGIS:
git clone [email protected]:qgis/QGIS-Documentation.git
También puede echar un vistazo al fichero “readme” incluido en la documentación del repositorio para obtener más información
Fuentes del sitio web de QGIS¶
Si esta interesado en verificar las fuentes en el sitio web de QGIS:
git clone [email protected]:qgis/QGIS-Website.git
También se puede dar un vistazo al documento readme incluido con la el repositorio del sitio web para mayor información.
Documentación sobre GIT¶
Consulte los siguientes sitios para obtener información acerca de cómo convertirse en un maestro de GIT.
Desarrollo usando ramas¶
Objetivo¶
The complexity of the QGIS source code has increased considerably during the last years. Therefore it is hard to anticipate the side effects that the addition of a feature will have. In the past, the QGIS project had very long release cycles because it was a lot of work to reestablish the stability of the software system after new features were added. To overcome these problems, QGIS switched to a development model where new features are coded in GIT branches first and merged to master (the main branch) when they are finished and stable. This section describes the procedure for branching and merging in the QGIS project.
Procedimiento¶
- Anuncio inicial en la lista de correo:
Antes de comenzar, haga un anuncio en la lista de correo de desarrollo para ver si otro desarrollador está ya trabajando en la misma funcionalidad. Contacte también con el asesor técnico del comité directivo del proyecto (PSC). Si la nueva funcionalidad requiere algún tipo de cambio en la arquitectura de QGIS, será necesaria una petición de comentarios (RFC)
Crear una rama: Cree una nueva rama en GIT para el desarrollo de la nueva funcionalidad.
git checkout -b newfeature
Ahora puede empezar a desarrollar. Si planea hacer tareas de larga duración en dicha rama, desea compartir el trabajo con otros desarrolladores, y tener acceso de escritura al repositorio padre, puede enviar su repositorio al repositorio oficial de QGIS haciendo lo siguiente:
git push origin newfeature
Nota
Si en la rama ya existe sus cambios serán introducidos en él.
Restablecer desde la rama principal de forma regular: Es recomendable reestablecer (“rebase”) para incorporar los cambios realizados en la rama principal a la rama de forma regular. Esto facilita la fusión de la rama nueva a la maestra más tarde. Después de reestablecer la base es necesario ejecutar el comando git push -f en el repositorio bifurcado.
Nota
¡Nunca haga git push -f al repositorio original! Utilice esto sólo durante el trabajo en la rama.
git rebase master
Realice las pruebas necesarias antes de volver a fusionar a la rama principal¶
Cuando esté terminada la nueva funcionalidad y esté contento con la estabilidad, haga un anuncio en la lista de desarrollo. Antes de fusionar de nuevo, los cambios serán probados por los desarrolladores y usuarios.
Enviando parches y peticiones de incorporación de cambios (“Pull Requests”)¶
Existen algunas pautas que lo ayudarán a conseguir que sus parches y peticiones de incorporación de cambios (“pull requests”) formen parte de QGIS fácilmente, y nos ayudarán a facilitar el uso de los parches que se envían.
Peticiones de incorporación de cambios (“Pull Requests”)¶
En general es más fácil para los desarrolladores si se envían peticiones de incorporación de cambios de GitHub. No describiremos en qué consisten las peticiones de incorporación de cambios aquí, sino que le recomendamos leer la Documentación de peticiones de incorporación de cambios en GitHub.
If you make a pull request we ask that you please merge master to your PR branch regularly so that your PR is always mergeable to the upstream master branch.
Si es desarrollador y desea evaluar la cola de peticiones de incorporación de cambios, hay una herramienta muy amigable que le permite hacer esto desde línea de comandos
Por favor, consulte el apartado a continuación sobre “cómo alertar de su parche. En general, cuando envíe una petición de incorporación de cambios debe asumir la responsabilidad de seguirla hasta su finalización - responder a las preguntas publicadas por otros desarrolladores, buscar un “campeón” para su funcionalidad y recordarles de manera amable si detecta que su petición no está siendo revisada. Tenga en cuenta que el proyecto QGIS está impulsado por el esfuerzo voluntario y es posible que las personas no puedan revisar su petición de incorporación de cambios de forma instantánea. Si cree que la petición no está recibiendo la atención que merece sus opciones para acelerarla deberían ser (en orden de prioridad):
Envíe un mensaje a la lista de correo “promocionando” su petición de incorporación de cambios y qué maravilloso sería incluirlo en el código base.
Envíe un mensaje a la persona a la que se le asignó su petición de incorporación de cambios en la cola de peticiones de incorporación de cambios.
Envíe un mensaje a Marco Hugentobler (es quién gestiona la cola de peticiones de incorporación de cambios).
Envíe un mensaje al comité directivo del proyecto pidiendo que le ayuden a incorporar su petición de incorporación de cambios en el código base.
Mejores prácticas para la creación de una petición de incorporación de cambios¶
Inicie siempre una rama para una nueva funcionalidad a partir de la rama principal actual.
Si está programando en una rama una nueva funcionalidad, no “”fusione”” (“merge”) nada en dicha rama; en lugar de ello use la opción de restablecer la base (“rebase”) como se indica en el siguiente punto para mantener su historial limpio.
Antes de crear una petición de incorporación de cambios ejecute
git fetch originygit rebase origin/master(dado que el origen es repositorio padre remoto y no su propio remoto, verifique su fichero.git/configo ejecute `` git remote -v | grep github.com / qgis``).Puede hacer una reestablecer la base (“rebase”) de git como en la última línea repetidamente sin hacer ningún daño (siempre y cuando el único propósito de su rama sea fusionarse con la rama principal).
Atención: después de un rebase necesitará ejecutar
git push -fen su repositorio bifurcado. DESARROLLADORES DEL NÚCLEO: NO HAGAN ESTO EN EL REPOSITORIO PÚBLICO DE QGIS!
Etiquetas especiales para notificar a los documentadores¶
Además de las etiquetas comunes que puede añadir a su petición de incorporación de cambios para clasificarla, existen otras etiquetas especiales que puede usar para generar de forma automática informes de incidencias en el repositorio de documentación de QGIS tan pronto como su petición de incorporación de cambios se fusione:
[needs-docs]para indicar a los redactores de documentación que agreguen documentos extra después de una corrección o mejora de una funcionalidad ya existente.[feature]in case of new functionality. Filling a good description in your PR will be a good start.
Desarrolladores, utilicen por favor estas etiquetas (no distingue entre mayúsculas y minúsculas) para que los redactores de documentos tengan incidencias en las que trabajar y tengan una visión general de las cosas pendientes por hacer. PERO por favor dediquen también tiempo para añadir algo de texto: ya sea en el mensaje al guardar los cambios o en la documentación.
Para fusionar una petición de incorporación de cambios¶
Opción A:
Pulse sobre el botón fusionar (“merge”) (Crea una fusión que no es de avance rápido)
Opción B:
Prueba (también se necesita para la opción A, obviamente)
verificar master, fusión git pr/1234
Opcional:
git pull --rebase: Crea un avance rápido, no se hace «merge commit». El historial estará más limpio, pero será más difícil revertir la fusión.git push(NUNCA JAMÁS utilizar la opción -f aquí)
Política de nombres para ficheros de parches¶
Si el parche es una solución para un error específico, nombre el archivo con el número de error, p. bug777fix.patch y adjúntelo al informe de error original en GitHub <https://github.com/qgis/QGIS/issues> _.
Si el error es una mejora o una nueva característica, generalmente es una buena idea crear un ticket en GitHub <https://github.com/qgis/QGIS/issues> _ primero y luego adjunte su parche.
Cree su parche en el directorio fuente QGIS de nivel superior¶
De esta forma es más fácil de aplicar los parches ya que no necesitamos navegar a un lugar específico del código fuente para aplicar el parche. Además, cuando recibo parches, generalmente los evalúo usando “merge”, y estando el parche en el directorio de nivel superior hace que esto sea mucho más fácil. A continuación se muestra un ejemplo de cómo puede incluir varios archivos modificados en su parche desde el directorio de nivel superior:
cd QGIS
git checkout master
git pull origin master
git checkout newfeature
git format-patch master --stdout > bug777fix.patch
Esto asegurará que su rama maestra esté sincronizada con el repositorio original, y luego generará un parche que contiene las diferencias entre su rama con los cambios y lo que está en la rama maestra.
Llamando la atención sobre su parche¶
Los desarrolladores de QGIS son gente ocupada. Escaneamos los parches entrantes en los informes de errores, pero a veces echamos de menos cosas. No se ofenda ni se alarme. Intente identificar a un desarrollador para que lo ayude y contáctelos preguntándoles si pueden ver su parche. Si no recibe ninguna respuesta, puede escalar su consulta a uno de los miembros del Comité Directivo del Proyecto (los detalles de contacto también están disponibles en Recursos Técnicos).
Obteniendo acceso de escritura en GIT¶
El acceso de escritura al árbol fuente de QGIS es por invitación. Normalmente, cuando una persona envía varios parches (no hay un número fijo) que demuestren la competencia básica y la comprensión de las convenciones de codificación C++ y de QGIS, uno de los miembros del PSC u otros desarrolladores existentes pueden nominar a esa persona al PSC para otorgar acceso de escritura . El nominador debe proporcionar un párrafo promocional básico de por qué creen que esa persona debe obtener acceso de escritura. En algunos casos otorgaremos acceso de escritura a desarrolladores que no sean de C++, p. ej., para traductores y documentadores. En estos casos, la persona aún así debe haber demostrado la capacidad de enviar parches y lo ideal es que haya enviado varios parches sustanciales que demuestren su comprensión de la modificación del código fuente base sin romper las cosas, etc.
Nota
Desde que nos mudamos a GIT es menos probable que otorguemos acceso de escritura a los nuevos desarrolladores, ya que es trivial compartir código dentro de github creando una bifurcación de QGIS y generando peticiones de incorporación de cambios.
Verifique siempre que todo compila antes de realizar cualquier solicitud de confirmación / petición de incorporación de cambios. Intente tener en cuenta las posibles roturas que sus confirmaciones pueden causar a las personas que compilan en otras plataformas y con versiones más antiguas / más nuevas de las librerías.
Al realizar una confirmación, aparecerá su editor (como se define en la variable de entorno $EDITOR) y debería hacer un comentario en la parte superior del archivo (encima del área que dice “no cambiar esto”). Ponga un comentario descriptivo y es mejor hacer varias pequeñas confirmaciones si los cambios realizados a un conjunto de archivos no están relacionados. Por el contrario, preferimos que agrupe los cambios relacionados en una única confirmación.