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.
Si vous lisez ces lignes, c’est sûrement parce que vous souhaitez contribuer à écrire la documentation de QGIS et cherchez un guide pratique. Vous êtes au bon endroit! Ce document vous guidera à travers les différentes façons d’atteindre cet objectif, vous indiquant les étapes principales, les astuces que vous pouvez utiliser et les pièges dont vous devez vous méfier.
For any help, do not hesitate to either ask in a comment on the issue report you are trying to fix or write to the QGIS-community-team list. More details at Get involved in documentation.
Let’s now dive into the process.
Documentation sources are stored using the git version control system and are available on GitHub at https://github.com/qgis/QGIS-Documentation. There are two main ways, not mutually exclusive, to modify the files:
Utiliser l’interface web de GitHub¶
L’interface web de GitHub vous permet de faire comme suit:
éditer des fichiers
prévisualiser et valider vos changements
Créer une pull request pour ajouter vos modifications dans le répertoire principal.
Créer, mettre à jour ou supprimer des branches
If you are not yet familiar with git and GitHub vocabulary, you may want to read the GitHub Hello-world project to learn some basic vocabulary and actions that will be used below.
Note
Si vous corrigez un problème signalé
Si vous comptez apporter des corrections à un signalement, ajoutez un commentaire au rapport d’erreur afin de vous le faire assigner. Ceci empêchera que plus d’une personne travaille sur la même erreur.
1. « Forker » QGIS-Documentation¶
Dans l’hypothèse où vous avez déjà un compte GitHub, il vous faudra d’abord cloner les fichiers source de la documentation.
Naviguez vers la page QGIS-Documentation repository et cliquez sur le bouton en haut à droite.
In your GitHub account you will find a QGIS-Documentation repository
(https://github.com/<YourName>/QGIS-Documentation
).
This repository is a copy of the official QGIS-Documentation repository where
you have full write access and you can make changes without affecting the
official documentation.
2. Faire des changements¶
Il y a différentes façons de contribuer à la documentation QGIS. Bien que nous les exposions ci-dessous séparément, vous pouvez passer d’un processus à l’autre sans risque.
Alternative 1: Utiliser le raccourci Corrigez-moi
¶
Les pages sur le site QGIS peuvent être éditées rapidement et facilement en cliquant sur le lien Corrigez-moi
situé en bas de page.
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 to a new branch of your repository.Do your changes. Since the documentation is written using the reStructureText syntax, depending on your changes, you may need to rely on the writing guidelines.
When you finish, make a short comment about your changes and click on Propose file change. This will generate a new branch (
patch-xxx
) in your repository.After you click on Propose file change github will navigate to the Comparing changes page.
If you’re done making changes, skip to Compare changes in the Share your changes via Pull Request section below.
S’il y a des changements supplémentaires à effectuer avant de les soumettre à QGIS, suivez ces étapes :
Navigate to your fork of QGIS-Documentation (
https://github.com/<YourName>/QGIS-Documentation
)Click on and search for the
patch-xxx
branch. Select this patch branch. The button will now say Branch: patch-xxxJump down to Modify files below.
Alternative 2 : Créer une branche ad hoc dans votre dépôt de documentation¶
You can edit files directly from your fork of the QGIS Documentation.
Click on in the upper left corner of your forked QGIS- Documentation repository and enter a unique name in the text field to create a new branch . The name of the new branch should relate to the problem you intend to fix. The button should now say Branch: branch_name
Astuce
Do your changes in an ad hoc branch, never in the master
branch
By convention, avoid making changes in your master
branch except when
you merge the modifications from the master
branch of qgis/QGIS-Documentation
into your copy of the QGIS-Documentation repository.
Separate branches allow you to work on multiple problems at the same time
without interfering with other branches. If you make a mistake you can
always delete a branch and start over by creating a new one from the master
branch.
3. Modifier des fichiers¶
Browse the source files of your fork of QGIS-Documentation to the file that needs to be modified
Procédez à vos modifications en suivant les règles d’écriture.
When you finish, navigate to the Commit Changes frame at the bottom of the page, make a short comment about your changes, and click on Commit Changes to commit the changes directly to your branch. Make sure Commit directly to the branch_name branch. is selected.
Repeat the previous steps for any other file that needs to be updated to fix the issue
5. Delete your merged branch¶
You can delete the branch after your changes have been merged. Deleting old branches saves you from having unused and outdated branches in your repository.
Navigate to your fork of the QGIS-Documentation repository (https://github.com/<YourName>/QGIS-Documentation
).
Click on the Branches tab. Below Your branches you’ll
see a list of your branches. Click on the Delete this
branch icon to delete any unwanted branches.
Utiliser les outils de ligne de commande Git¶
The GitHub web interface is an easy way to update the QGIS-documentation repo with your contributions, but it doesn’t offer tools to:
group your commits and clean your change history
fix possible conflicts with the main repo
construire la documentation pour tester vos modifications
You 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¶
Now you are ready to get a local clone of your QGIS-Documentation repository.
You can clone your QGIS repository using the web URL as follows:
# move to the folder in which you intend to store the local repository
$ cd ~/Documents/Development/QGIS/
$ git clone https://github.com/<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.
Check the following:
# Enter the local repository
$ cd ./QGIS-Documentation
$ git remote -v
origin https://github.com/<YourName>/QGIS-Documentation.git (fetch)
origin https://github.com/<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!
Alternatively you can clone your QGIS repository using the SSH protocol:
# move to the folder in which you intend to store the local repository
$ cd ~/Documents/Development/QGIS/
$ git clone git@github.com:<YourName>/QGIS-Documentation.git
Astuce
Permission denied (publickey) error?
If you get a Permission denied (publickey) error with the former command, there may be a problem with your SSH key. See GitHub help for details.
Check the following if you used the SSH protocol:
# Enter the local repository
$ cd ./QGIS-Documentation
$ git remote -v
origin git@github.com:<YourName>/QGIS-Documentation.git (fetch)
origin git@github.com:<YourName>/QGIS-Documentation.git (push)
$ git branch
* master
You can start to work here but in the long terme process you will get a lot of issue when you will push your contribution (called Pull Request in github process) as the master branch of the QGIS-Documentation repository will diverge from your local/remote repository. You then need to keep track of the main remote repository and work with branches.
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 https://github.com/qgis/QGIS-Documentation.git
$ git remote -v
origin https://github.com/<YourName>/QGIS-Documentation.git (fetch)
origin https://github.com/<YourName>/QGIS-Documentation.git (push)
upstream https://github.com/qgis/QGIS-Documentation.git (fetch)
upstream https://github.com/qgis/QGIS-Documentation.git (push)
Similarly, you can use the SSH protocol to add a remote repository in your local repository:
$ git remote add upstream git@github.com:qgis/QGIS-Documentation.git
$ git remote -v
origin git@github.com:<YourName>/QGIS-Documentation.git (fetch)
origin git@github.com:<YourName>/QGIS-Documentation.git (push)
upstream git@github.com:qgis/QGIS-Documentation.git (fetch)
upstream git@github.com: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¶
Before working on a new contribution, you should always update your master branch in your local repository. Assuming you are willing to push changes to the testing documentation, run the following command lines:
# switch to master branch (it is easy to forget this step!)
$ git checkout master
# get "information" from the master branch in the 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 (aka <YourName>/QGIS-Documentation)
$ git push origin master
Now you have your local and remote repositories which both have their master
branch up to date with the official master
branch of QGIS-Documentation.
You can start to work on your contribution.
Note
Switch the branch if you wish to contribute to released doc
Along with the testing documentation, we continue to fix issues in QGIS 3.4 doc,
meaning that you can also contribute to it. Follow the previous section sample code,
replacing master
with the corresponding branch of the latest documentation.
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!
# Create a new branch
$ git checkout -b myNewBranch
# checkout means go to the branch
# and -b flag creates a new branch if needed, based on current branch
# Let's check the list of existing branches (* indicates the current branch)
$ git branch
master
release_2.18
...
* myNewBranch
# You can now add your contribution, by editing the concerned file(s)
# 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 avecFix
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
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!
Further reading¶
Other than the Github web interface and the git command line tools exposed above, there are also GUI applications you can use to create and manage your contributions to the documentation.
When the changes in the pull request are conflicting with recent changes pushed to the target branch, the conflicts need to be resolved before a merge is possible:
if the conflict relates to few competing lines, a Resolve conflicts button is available in the Github pull request page. Press the button and resolve the issue as explained at https://help.github.com/articles/resolving-a-merge-conflict-on-github/
if the conflict involves files renaming or removal, then you’d need to resolve the conflict using git command lines. Typically, you have to first rebase your branch over the target branch using
git rebase targetBranch
call and fix the conflicts that are reported. Read more at https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/
Sometimes, at the end of the proofreading process, you may end up with changes split into multiple commits that are not necessarily worth it. Git command lines help you squash these commits to a smaller number and more meaningful commit messages. Some details at https://help.github.com/articles/using-git-rebase-on-the-command-line/