Outdated version of the documentation. Find the latest one here.

Acceso GIT

Esta seccion describe como empeza a usar el repositorio GIT de QGIS. Antes de que puedas hacer esto, primero necesitas tener un cliente git instalado en tu sistema.

Instalación

Instalar git para GNU/Linux

Los usuarios de distro basadas en Debian pueden hacer:

sudo apt-get install git

Instale git para Windows

Windows users can obtain msys git or use git distributed with cygwin.

Instale git para OSX

The git project has a downloadable build of git. Make sure to get the package matching your processor (x86_64 most likely, only the first Intel Macs need the i386 package).

Una vez descargado, abra la imagen del disco y ejecute el instalador

nota PPC/fuente

El sitio de git no ofrece compilaciones PPC. Si se necesita una, o solo quiere más control sobre la instalación, es necesario que lo compile usted mismo.

Download the source from http://git-scm.com/. Unzip it, and in a Terminal cd to the source folder, then:

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=

Acceda al repositorio

Para clonar QGIS maestro:

git clone git://github.com/qgis/QGIS.git

Revisar branch

Para validar un branch, por ejemplo, el branch de lanzamiento 2.6.1 hace:

cd QGIS
git fetch
git branch --track origin release-2_6_1
git checkout release-2_6_1

Para validar el branch maestro:

cd QGIS
git checkout master

Nota

En QGIS, mantenemos nuestro código más estable en el branch de lanzamiento actual. El Master contiene código para la serie de versiones llamadas ‘inestables’. Periódicamente publicaremos una versión de master y luego continuaremos con la estabilización y la incorporación selectiva de nuevas funciones en master.

Vea el archivo INSTALL en el árbol de fuentes para obtener instrucciones especificas sobre la creación de versiones de desarrollo

Fuentes de documentación QGIS

Si estas interesado en verificar la documentacion fuente de QGIS:

git clone [email protected]:qgis/QGIS-Documentation.git

También puede dar un vistazo al documento readme incluido en la documentación del repositorio para 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 GIT

Vea los siguientes sitios para información de como volverse un maestro GIT.

Desarrollo en branches

Propósito

La complejidad del código fuente de QGIS se ha incrementado considerablemente durante los últimos años. Por lo tanto es difícil anticipar los efectos secundarios que traerá añadir una nueva. En el pasado, el proyecto QGIS tenia ciclos de lanzamiento muy largos porque era mucho trabajo reequilibrar la estabilidad del sistema de software después de que nuevos elementos se añadieron. Para superar estos problemas, QGIS cambio un modelo de desarrollo donde los nuevos elementos son codificados en branches de GIT primero y se fusionan al master (el branch principal) cuando están terminadas y estables. Esta sección describe el procedimiento para ramificar y fusionar el proyecto QGIS.

Procedimiento

  • Anuncio inicial en lista de correo:

    Antes de comenzar, haga un anuncio en la lista de correo de desarrollo para ver si otro desarrollador esta trabajando en el mismo característica. También contacte al asesor técnico del comité directivo del proyecto (PSC). Si la nueva característica requiere algún cambio de la arquitectura de QGIS, se necesita una petición de comentarios (RFC)

Crear un branch: Cree un nuevo GIT branch para el desarrollo del nuevo elemento.

git checkout -b newfeature

Ahora puede comenzar con el desarrollo. Si planea hacer extensas tareas en ese branch, y desea compartir el trabajo con otros desarrolladores, y tener acceso de escritura al repositorio en sentido ascendente, puede enviar su repositorio al repositorio oficial de QGIS haciendo:

git push origin newfeature

Nota

Si en le branch ya existen sus cambios serán introducidos a él.

Rebase para masterizar regularmente: es recomendable para volver a establecer la base para incorporar los cambios en el master del branch en una 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 ``git push -f`` para el repositorio bifucado.

Nota

Nunca haga git push -f al repositorio original! solo utilice esto para su trabajo de branch.

git rebase master

Documentation on wiki

It is also recommended to document the intended changes and the current status of the work on a wiki page.

Pruebe antes de volver a fusionar al master

Cuando este terminada la nueva característica y este 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.

Envío de parches y solicitudes de extracción

Hay algunas pautas que lo ayudaran a obtener sus parches y solicitudes de extracción en QGIS fácilmente, y nos ayudaran a mejorar los parches que se envían para utilizar fácilmente.

Pull Requests

En general es más fácil para los desarrolladores si envían solicitudes de extracción. Nosotros no describimos solicitudes de extracción aquí, sino que remitimos a Documentación de solicitud de extracción en GitHub.

Si realiza una solicitud de extracción, le pedimos que combine el master con su branch de PR con regularidad, de modo que su PR siempre se pueda combinar con la rama principal ascendente.

If you are a developer and wish to evaluate the pull request queue, there is a very nice tool that lets you do this from the command line

Por favor, consulte la sección a continuación sobre ‘obtener su parche notado’. En general, cuando envía un PR, debe asumir la responsabilidad de seguirlo hasta el final - responder a las consultas publicadas por otros desarrolladores, buscar un ‘campeón’ para su función y darles un ligero recordatorio ocasionalmente si ve que su PR no siendo actuado Tenga en cuenta que el proyecto QGIS está impulsado por el esfuerzo voluntario y es posible que las personas no puedan asistir a su PR instantáneamente. Si siente que el PR no está recibiendo la atención que merece sus opciones para acelerar, debe ser (en orden de prioridad):

  • Envié un mensaje a la lista de correo ‘marketing’ su PR y que maravilloso será incluirlo en la base del código.

  • Envié un mensaje a la persona a la que se le asigno su PR en la cola de PR.

  • Envíe un mensaje a Marco Hugentobler (quién gestiona la cola de PR).

  • Envié un mensaje al comite directivo del proyecto pidiendo que le ayuden a incorporar su PR en el código base.

La mejor practica para crear una solicitud de extracción

  • Siempre inicie un branch por característica del actual master.

  • Si estas codificando un branch de característica, no ‘’fusionar’’ nada a ese branch, en lugar de rebase como se describe en el siguiente punto para mantener su historial limpio.

  • Antes de crear una solicitud de extracción realice git fetch origin`` y  ``git rebase origin/master (el origen dado es el control remoto para la conexión ascendente y no su propio control remoto, verifique su .git/config o haga `` git remote -v | grep github.com / qgis``).

  • Puedes hacer una rebase git como en la última línea repetidamente sin hacer ningún daño (siempre y cuando el único propósito de tu branch sea fusionarse con el master).

  • Atención: después de un rebase se necesita git push -f a su repositorio bifucado. DESARROLLO BÁSICO: NO HACER ESTO EN EL REPOSITORIO PÚBLICO DE QGIS!

Etiquetas especiales para notificar a los documentadores

Además de las etiquetas comunes puede añadir para clasificar su PR, existen otras especiales que puede usar para generar automáticamente informes de problemas en el repositorio de documentación-QGIS tan pronto como su solicitud de extracción se fusione.

  • [needs-docs] para instruir a los escritores de documentos que agreguen documentos extra después de una corrección o añadir a una funcionalidad ya existente.

  • [feature] en caso de una nueva funcionalidad. Llenar una buena descripción en su PR será un buen comienzo.

Por favor desarrolladores utilicen estas etiquetas (no distingue entre mayúsculas y minúsculas) para que los redactores de documentos tengan problemas para trabajar y tengan una visión general de las cosas por hacer. PERO por favor, tome el tiempo para añadir algo de texto: en la confirmación O en los documentos.

Para fusionar una solicitud de extracción

Opción A:

  • clic sobre le botón de fusión (Crea una fusión no rápida)

Opcion B:

  • Verificar la solicitud de extracción

  • Prueba (también se requiere 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”. Limpiar historial, pero será difícil revertir la fusión.

  • git push (NUNCA JAMÁS utilizar la opción -f, aquí)

Nombramiento de archivos de parche

If the patch is a fix for a specific bug, please name the file with the bug number in it e.g. bug777fix.patch, and attach it to the original bug report in trac.

If the bug is an enhancement or new feature, its usually a good idea to create a ticket in trac first and then attach your patch.

Cree su parche en el directorio fuente QGIS de nivel superior

Esta es la forma más fácil de aplicar los parches ya que no necesitamos navegar a un parche específico. Además, cuando recibe parches, generalmente los evalúo usando merge, y tener el parche del 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 en sentido ascendente, y luego generará un parche que contiene el delta entre su rama de características y lo que está en la rama maestra.

Haga que se note su parche

QGIS developers are busy folk. We do scan the incoming patches on bug reports but sometimes we miss things. Don’t be offended or alarmed. Try to identify a developer to help you - using the Technical Resources and contact them asking them if they can look at your patch. If you don’t get any response, you can escalate your query to one of the Project Steering Committee members (contact details also available in the Technical Resources).

Debida diligencia

QGIS esta bajo licencia GPL. Debe hacer todos los esfuerzos posibles para garantizar que solo envíe parches que no estén sujetos a derechos de propiedad intelectual contradictorios. Además, no envíe un código que no esté satisfecho de haber puesto a disposición en virtud de la GPL.

Obtención de acceso de escritura 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 aquí) que demuestren la competencia básica y la comprensión de las convenciones de codificación C++ y 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 dar 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 C++, p. ej., para traductores y documentadores. En estos casos, la persona aún 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 de la base de códigos 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 mediante la falsificación de QGIS y la emisión de solicitudes de extracción.

Siempre verifique que todo se compila antes de realizar cualquier solicitud de confirmación / extracción. Intente tener en cuenta las posibles roturas que sus confirmaciones pueden causar a las personas que compilan en otras plataformas y con las 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á hacer un comentario en la parte superior del archivo (encima del área que dice ‘no cambiar esto’). Ponga un comentario descriptivo y en lugar de hacer varias pequeñas confirmaciones si los cambios en una serie de archivos no están relacionados. Por el contrario, preferimos que agrupe los cambios relacionados en una única confirmación.