Une contribution étape par étape

Note

Bien que la documentation de QGIS soit utilisée pour expliquer le processus, toutes les commandes et étapes montrées en-dessous sont également applicables au site web de QGIS.

Now that you know the rules to follow to write a clean doc for QGIS, let’s dive in the process of production of this documentation and how quickly and safely share your changes with the community.

Assuming you already have a GitHub account, you first need to clone the source files of the documentation in order to have your own copy you can work on: go to the QGIS-Documentation repository page (for convenience, this repository is called below qgis/QGIS-Documentation) and click on the Fork button in the upper right corner.

Few seconds later, in your GitHub account you find a QGIS-Documentation repository (https://github.com/<YourName>/QGIS-Documentation). This repo is a safe copy in which you have full write access and can push all your contributions without a risk to affect the official documentation. At the beginning, this repository contains the same branches as qgis/QGIS-Documentation and is defaulted to master branch. Branches are parallel lines of development containing different snapshots of the doc that may merge or diverge. Preferably create a branch for each issue you want to tackle and you can create as many branches as you want.

Astuce

Do your changes in an ad’hoc branch, never in master

By convention, avoid making changes in your master branch except merging the modifications from the master branch of qgis/QGIS-Documentation (called qgis:master). And use it as model to create new branches for a clean history and snapshot.

There are different ways to contribute to QGIS documentation. Though we expose them below separately, they are not mutually exclusive, meaning that you can, at any moment, switch from one process to another without any harm because they both follow the scheme below:

  1. Do your modifications in an ad’hoc branch of your repository
  2. Publish your changes and ask for merging in the main doc through a pull request (PR)
  3. Others review, discuss and integrate your work in the main branch when everything seems ok.

Using GitHub web interface

From your cloned repository, you can now propose changes to the main documentation. Indeed, GitHub web interface offers you ways to easily:

  • edit files, preview and commit your changes
  • make a pull request to have your changes inserted in the main repo
  • create, update or delete branches

Lire le projet GitHub Hello-world pour apprendre les bases du vocabulaire et des actions qui seront utilisées ci-dessous.

Make changes in your repo

Documentation can be improved by addressing issues reported at https://github.com/qgis/QGIS-Documentation/issues or issues you may have encountered while browsing the doc. They can be of different types: typo error, missing feature, wrong or out of date description...

Alternative 1: Picking an issue in the list

  1. Select an issue you want to fix. To avoid many persons tackling the same issue, you can inform contributors about your choice by adding a comment to the issue report and get it assigned to you.
  2. From your repository, create (and switch to) a branch with a name that helps you remind what it’s about
  3. Browse the source files to the file that has to be changed
  4. Toggle the file into Edit mode using the pencil icon and do your modifications following guidelines
  5. Validate your changes by filling the Commit Changes frame and commit directly to your branch.
  6. Redo the previous steps for any other file that needs to be updated to fix the issue.

Alternative 2: Using the Fix Me shortcut

The QGIS project provides an easy way to reach source file from online documentation. Indeed, instead of browsing the source files in GitHub to find the one that suits the issue, or if you find an issue while reading the manuals, you simply have to click the “Fix Me” link at the bottom of the page to open its source file in Edit mode.

  1. This will open the file in the qgis:master branch with a message at the top of the page telling you that you don’t have write access to this repo and your changes will be applied in a new branch of your repository.

    Note that if you have commit rights to QGIS-Documentation repository, then no message will show and you’ll directly modify qgis:master branch itself unless you save your changes in another branch.

  2. Do your changes following guidelines available at http://docs.qgis.org/testing/en/docs/documentation_guidelines/

  3. When you finish, at the bottom of the page, comment a bit what your changes are about and click on Propose File change. This will generate a new branch (patch-xxx) in your repo.

Astuce

If your master branch is even with qgis:master, you can safely replace in the link qgis by <YourName>. In this case, once your changes are done, you need to check radioButtonOn Create a new branch for this commit and start a pull request and avoid modifying master.

Share your changes via Pull Request

Now, you have a new branch in QGIS with a file that diverge from qgis:master. To integrate your changes in the official documentation, you need to do a pull request.

  1. Actually, after you commit your changes, GitHub opens a new dialog comparing branches:

    • if you used the Fix Me without changing the url, then the comparison is between your patch-xxx branch and qgis:master (the base fork is qgis/QGIS-Documentation and its branch master).
    • if you used a branch you had named yourself then the comparison is done between that branch and your own master branch (the base is simply master). You therefore need to leave that page and follow the next step.

  2. In any case (including pushing branch to GitHub from command lines) you can create a new pull request at any moment from many pages. Simply go to the main page of the repository (yours or qgis), click on New Pull Request and Compare across forks (if needed). Ensure you select qgis/QGIS-Documentation with master as base branch and that the head fork is your repository <YourName>/QGIS-Documentation with your modified branch along.

    Astuce

    Though released and being translated, the documentation of QGIS 2.18 is still maintained and existing issues are fixed. If you plan to fix the issues in the current released doc, replace master branch by the appropriate manual_en_... branch in any of the steps exposed earlier.

  3. A green check along the compared branches shows that your changes can automatically be merged in the official doc. Click the Create pull request button. If you get a red cross, it means that the files you are modifying were not up to date with the branch you are targetting (a commit has been pushed to it since you create or last update your branch). You then need to use git command line tools to fix it.

  4. Fill the form if needed and click again Create pull request button.

  5. A new PR is added to https://github.com/qgis/QGIS-Documentation/pulls and everybody can look or comment it.

  6. That will trigger a Travis CI build automatically checking if your contribution doesn’t contain a build error. In case of error, a red cross appears along your commit. Simply click on it or on Details in the summary section at the bottom of the page to have details on the error. You’ll need to fix any reported error or warning before your changes are committed in the repository.

  7. Until your PR is merged with the main repo, you can add modifications to your proposal. Actually any new changes done to your branch is appended to your pull request. Do it if the change has to do with the issue you are fixing, otherwise create a new branch for those changes following steps above.

  8. Once everything looks good to you and others, a committer can merge your branch with the main repo. Your contribution is validated.

  9. If you want, you can now delete the branch you used, to avoid having too many (unused and outdated) branches crowding your repository.

Doing this little steps will make you learn the process easier.

Warning

Be vigilant to pull request against qgis:master and not your own master branch, otherwise nobody is aware of your changes and you may mistakenly merge your changes into your master branch, polluting its history.

Astuce

Automatically close issue report from pull request

To ease issue reports management, mention the number of the issue you are addressing in your pull-request. This can be done using #issue_number. If preceded by terms like fix, close... the concerned issue is closed as soon as the pull request is merged.

Utiliser les outils de ligne de commande Git

GitHub web interface helps you update the repo with your contribution in an easier way but it doesn’t offer tools to:

  • group your commits and clean your changes history
  • fix conflicts with the main repo if needed...

  • construire la documentation pour tester vos modifications

You then need to install git on your hard drive in order to get access to more advanced and powerful tools and have a local copy of the repository. Some basics you may often need are exposed below. You’ll also find rules to care about even if you opt for the web interface.

Dans les exemples de code ci dessous, les lignes commençant par $ représente les commandes que vous aurez à taper, alors que les # sont des commentaires.

Dépôt local

Maintenant, vous êtes prêt à récupérer un clone local de votre dépôt QGIS-Documentation

$ cd ~/Documents/Development/QGIS/
$ git clone [email protected]:<YourName>/QGIS-Documentation.git

La ligne de commande précédente n’est qu’un exemple. Il faut adapter le chemin et l’URL du dépôt en remplaçant “<YourName>” par votre nom d’utilisateur.

Astuce

Permission denied (publickey) error?

Si vous avez un message “Permission denied (publickey) error”, il pourrait y avoir un problème avec votre clé SSH. Consultez GitHub help pour plus de précisions.

Vérifier le :

$ git remote -v
origin  [email protected]:<YourName>/QGIS-Documentation.git (fetch)
origin  [email protected]:<YourName>/QGIS-Documentation.git (push)
$ git branch
* master

  • origin est le nom du dépôt distant de votre dépôt QGIS-Documentation.

  • master est la branche principale par défaut. Vous ne devriez jamais l’utiliser pour vos contributions ! Jamais!

Vous pouvez commencez à travailler d’ici, mais à la longue, vous aurez beaucoup d’erreurs lorsque vous voudrez soumettre vos contributions (appelées Pull Request dans la procédure de GitHub) étant donné que la branche principale du dépôt QGIS-Documentation divergera de votre dépôt local/distant.

Ajoutez un autre dépôt distant

Pour pouvoir suivre l’avancement du travail réalisé sur le projet principal, ajoutez un nouveau dépôt distant dans votre dépôt local. Ce nouveau dépôt distant sera le dépôt QGIS-Documentation du projet QGIS :

$ git remote add upstream [email protected]:qgis/QGIS-Documentation.git
$ git remote -v
origin  [email protected]:<YourName>/QGIS-Documentation.git (fetch)
origin  [email protected]:<YourName>/QGIS-Documentation.git (push)
upstream        [email protected]:qgis/QGIS-Documentation.git (fetch)
upstream        [email protected]:qgis/QGIS-Documentation.git (push)

Désormais, vous avez le choix entre deux dépôts distants :

  • origin pour “pousser” votre branche locale dans votre dépôt distant

  • upstream pour fusionner (si vous avez les droits pour le faire) votre contribution avec le dépôt officiel OU pour mettre à jour votre branche “master” sur le dépôt local à partir de la branche “master” du dépôt officiel.

Note

upstream est juste un intitulé, une sorte de nom standard, mais vous pouvez l’appeler comme vous voulez.

Mettez à jour votre branche de base

Pour la documentation testing (branche master)

Avant de travailler sur une nouvelle contribution, vous devez toujours mettre à jour votre branche locale master dans votre dépôt local. Lancez simplement cette commande :

# switch to master branch (it is easy to forget this step!)
$ git checkout master
# get "information" from the master branch in upstream repository
# (aka qgis/QGIS-Documentation's repository)
$ git fetch upstream master
# merge update from upstream/master to the current local branch
# (which should be master, see step 1)
$ git merge upstream/master
# update **your** remote repository
$ git push origin master

Vous disposez maintenant d’un dépôt local et d’un dépôt distant qui ont tous deux une branche master à jour par rapport à QGIS-Documentation de l’organisation QGIS. Vous pouvez commencer à travailler sur votre contribution.

For released doc (manual_en_ branch)

Along the testing documentation, we continue to fix issues in QGIS 2.18 doc, meaning that you can also contribute to it. Following the previous section sample code, you can easily do that by selecting the corresponding branch.

Lorsque vous dupliquez le dépôt (voir Dépôt local), votre copie contient toutes les branches du dépôt père. Comme plus haut, vous devez vous assurer que votre branche est à jours avec les banches du dépôt père:

# change branch e.g. for 2.14 LTR
$ git checkout manual_en_2.14
# get "information" from the manual_en_2.14 branch in upstream repository
$ git fetch upstream manual_en_2.14
# merge update from upstream/manual_en_2.14 to the current local branch
$ git merge upstream/manual_en_2.14
# update **your** remote repository
$ git push origin manual_en_2.14

In this way your local and remote branches for the 2.14 version are up to date with the one of the official upstream repository.

Contribuez dans votre branche de production

Maintenant que la branche de base est mise à jour, il vous faut créer une branche spéciale pour accueillir vos modifications. Ayez le réflexe de toujours travailler sur une branche autre que celle de base - souvent la master! Toujours!

$ git checkout -b myNewBranch
# checkout means go to the branch
# and -b flag creates a new branch if needed, based on current branch
$ git branch
master
manual_en_2.14
* myNewBranch
# a list of existing branch where * means the current branch
# You can now add your contribution, by editing the concerned file
# with any application (in this case, vim is used)
$ vim myFile
# once done
$ git add myFile
$ git commit

Quelques remarques à propos des commandes de commit/push :

  • essayez de ne “commiter” qu’une seule contribution (changement atomique). En d’autres termes, n’adressez qu’une seule erreur à la fois.

  • essayez d’expliquer avec soin ce que vous avez modifié dans le titre de votre commit et dans la description. La première ligne est un titre, doit commencer par une lettre majuscule, devra contenir 80 caractères au maximum et ne devra pas se terminer par un .. Soyez concis. Votre description peut être plus longue et se termine par un .. Vous pouvez y donner plus de détails.

  • utilisez un # avec un nombre pour faire référence à un problème. Préfixez avec Fix si vous fixez le ticket: votre commit fermera le ticket.

Maintenant que vos modifications sont sauvegardées et intégrées dans votre branche locale, il va falloir les envoyer sur le dépôt en ligne, afin de pouvoir créer des pull-requests:

$ git push origin myNewBranch

Partagez vos modifications

Vous pouvez maintenant aller dans votre dépôt github et create a Pull Request comme expliqué dans une section précédente. Assurez-vous de créer un PR depuis votre branche vers la branche distante cible dans le dépôt officiel de QGIS-Documentation.

Nettoyez votre dépôt local et distant.

Une fois que votre PR a été fusionnée dans le QGIS-Documentation officiel, vous pouvez supprimer votre branche. En effet, si vous contribuez souvent, vous vous retrouverez d’ici quelques semaines avec un nombre considérable de branches inutilisées. Du coup, gardez votre dépôt propre de cette façon :

# delete local branch
$ git branch -d myNewBranch
# Remove your remote myNewBranch by pushing nothing to it
$ git push origin :myNewBranch

Et n’oubliez pas de mettre à jour la branche master dans votre dépôt local!