# Documentation Django 3.1.9.dev

# Travailler avec Git et GitHub

Cette section explique comment la communauté peur contribuer au code de Django au travers de requêtes de contribution (« pull requests »). SI vous vous intéressez à la manière dont les commiteurs les gèrent, consultez Commit de code.

Nous allons montrer ci-dessous comment créer une requête de contribution GitHub contenant les modifications pour un ticket Trac #xxxxx. En créant une requête de contribution totalement complète, vous faciliterez le travail des relecteurs, ce qui augmentera aussi la probabilité de voir votre code intégré dans Django.

Il est aussi possible de téléverser un correctif traditionnel dans Trac, mais c’est moins pratique pour la relecture.

## Installation de Git

Django utilise Git comme système de gestion de version. Vous pouvez télécharger Git, mais il est souvent plus simple de l’installer avec le gestionnaire de paquets de votre système d’exploitation.

Le dépôt GIt de Django est hébergé sur GitHub, et nous vous recommandons aussi de travailler avec GitHub.

Après l’installation de Git, la première chose à faire est de configurer votre nom et votre courriel

    $ git config --global user.name "Your Real Name"
    $ git config --global user.email "you@email.com"

Notez que `user.name` devrait être votre nom réel, pas un alias GitHub. GitHub devrait reconnaître le courriel que vous indiquez dans le champ `user.email`, car il sera utilisé pour associer vos commits avec votre compte GitHub.

## Configuration d’un dépôt local

Un fois votre compte GitHub créé, avec le pseudonyme « GitHub_nick », et le dépôt Django cloné, créez une copie locale de votre clone :

    git clone https://github.com/GitHub_nick/django.git

This will create a new directory « django », containing a clone of your GitHub repository. The rest of the git commands on this page need to be run within the cloned directory, so switch to it now:

    cd django

Votre dépôt GitHub sera appelé « origin » dans Git.

You should also setup `django/django` as an « upstream » remote (that is, tell git that the reference Django repository was the source of your fork of it):

    git remote add upstream git@github.com:django/django.git
    git fetch upstream

You can add other remotes similarly, for example:

    git remote add akaariai git@github.com:akaariai/django.git

## Working on a ticket

Lorsque vous travaillez sur un ticket, créez une nouvelle branche dédiée à ce travail e la basant sur upstream/master

    git checkout -b ticket_xxxxx upstream/master

L’option `-b` crée une branche locale. N’hésitez pas à créer de nouvelles branches même pour les plus petites choses, elles sont prévues pour ça.

Si par contre vous travailliez sur une correction dans la branche 1.4, vous auriez écrit

    git checkout -b ticket_xxxxx_1_4 upstream/stable/1.4.x

On part du principe que le travail se fait sur la branche ticket_xxxxx. Faites des modifications et validez-les par commit

    git commit

When writing the commit message, follow the commit message guidelines to ease the work of the committer. If you’re uncomfortable with English, try at least to describe precisely what the commit does.

If you need to do additional work on your branch, commit as often as necessary:

    git commit -m 'Added two more tests for edge cases'

### Publication de votre travail

Vous pouvez publier votre travail sur GitHub en exécutant

    git push origin ticket_xxxxx

Lorsque vous allez sur votre page GitHub, vous pouvez constater qu’une nouvelle branche a été créée.

Si vous travaillez à partir d’un ticket Trac, vous devriez mentionner dans le ticket que votre travail est disponible dans la branche ticket_xxxxx de votre dépôt GiHub. Incluez un lien vers votre branche.

Notez que la branche ci-dessus est appelée une branche thématique (« topic branch ») dans le jargon Git. Vous êtes libre de réécrire l’historique de cette branche, par exemple avec `git rebase`. D’autres personnes ne devraient pas baser leur travail sur une telle branche, car leur clone serait corrompu dès le moment où vous modifiez des commits.

Il existe aussi des branches publiques. Ce sont des branches que d’autres personnes sont susceptibles de fourcher, ce qui implique que leur historique ne devrait jamais être altéré. De bons exemples de branches publiques sont les branches `master` et `stable/A.B.x` dans le dépôt `django/django`.

Lorsque vous pensez que votre travail est prêt à être intégré dans Django, c’est le moment de créer une requête de contribution (pull request) dans GitHub. Une bonne requête de contribution signifie :

- des commits avec chacun son changement logique, respectant le style de code ;
- des messages correctement formés pour chaque commit : une ligne de résumé puis des paragraphes de lignes à 72 caractères - consultez les lignes directrices pour les commits pour plus de détails ;
- de la documentation et des tests, si nécessaire – en réalité, des tests sont toujours nécessaires à l’exception des modifications de documentation.

La suite de tests doit passer et la documentation doit pouvoir être construite sans avertissement.

Après avoir créà la requête de contribution, vous devriez ajouter un commentaire dans le ticket Trac correspondant en expliquant ce que vous avez fait. En particulier, vous devriez signaler l’environnement dans lequel vous avez lancé les tests, par exemple : « tous les tests passent avec SQLite et MySQL ».

Pull requests at GitHub have only two states: open and closed. The committer who will deal with your pull request has only two options: merge it or close it. For this reason, it isn’t useful to make a pull request until the code is ready for merging – or sufficiently close that a committer will finish it themselves.

### Rebasing branches

In the example above, you created two commits, the « Fixed ticket_xxxxx » commit and « Added two more tests » commit.

We do not want to have the entire history of your working process in your repository. Your commit « Added two more tests » would be unhelpful noise. Instead, we would rather only have one commit containing all your work.

To rework the history of your branch you can squash the commits into one by using interactive rebase:

    git rebase -i HEAD~2

The HEAD~2 above is shorthand for two latest commits. The above command will open an editor showing the two commits, prefixed with the word « pick ».

Change « pick » on the second line to « squash » instead. This will keep the first commit, and squash the second commit into the first one. Save and quit the editor. A second editor window should open, so you can reword the commit message for the commit now that it includes both your steps.

You can also use the « edit » option in rebase. This way you can change a single commit, for example to fix a typo in a docstring:

    git rebase -i HEAD~3
    # Choose edit, pick, pick for the commits
    # Now you are able to rework the commit (use git add normally to add changes)
    # When finished, commit work with "--amend" and continue
    git commit --amend
    # Reword the commit message if needed
    git rebase --continue
    # The second and third commits should be applied.

If your topic branch is already published at GitHub, for example if you’re making minor changes to take into account a review, you will need to force-push the changes:

    git push -f origin ticket_xxxxx

Note that this will rewrite history of ticket_xxxxx - if you check the commit hashes before and after the operation at GitHub you will notice that the commit hashes do not match anymore. This is acceptable, as the branch is a topic branch, and nobody should be basing their work on it.

### After upstream has changed

When upstream (`django/django`) has changed, you should rebase your work. To do this, use:

    git fetch upstream
    git rebase

The work is automatically rebased using the branch you forked on, in the example case using `upstream/master`.

The rebase command removes all your local commits temporarily, applies the upstream commits, and then applies your local commits again on the work.

If there are merge conflicts, you will need to resolve them and then use `git rebase --continue`. At any point you can use `git rebase --abort` to return to the original state.

Note that you want to rebase on upstream, not merge the upstream.

The reason for this is that by rebasing, your commits will always be on top of the upstream’s work, not mixed in with the changes in the upstream. This way your branch will contain only commits related to its topic, which makes squashing easier.

### After review

It is unusual to get any non-trivial amount of code into core without changes requested by reviewers. In this case, it is often a good idea to add the changes as one incremental commit to your work. This allows the reviewer to easily check what changes you have done.

In this case, do the changes required by the reviewer. Commit as often as necessary. Before publishing the changes, rebase your work. If you added two commits, you would run:

    git rebase -i HEAD~2

Squash the second commit into the first. Write a commit message along the lines of:

    Made changes asked in review by <reviewer>

    - Fixed whitespace errors in foobar
    - Reworded the docstring of bar()

Finally, push your work back to your GitHub repository. Since you didn’t touch the public commits during the rebase, you should not need to force-push:

    git push origin ticket_xxxxx

Your pull request should now contain the new commit too.

Note that the committer is likely to squash the review commit into the previous commit when committing the code.

## Travail sur un correctif

L’une des manières de contribuer à Django par les développeurs est de réviser des correctifs. Ces correctifs se trouvent habituellement sous la forme de requêtes de contribution (pull request) dans GitHub et peuvent facilement être intégrés dans un dépôt local

    git checkout -b pull_xxxxx upstream/master
    curl https://github.com/django/django/pull/xxxxx.patch | git am

Cela va créer une nouvelle branche, puis y appliquer les modifications de la requête de contribution. À ce stade, vous pouvez lancer les tests ou faire tout ce qu’il faut pour examiner la qualité du correctif.

Pour plus de détails sur le travail avec les requêtes de contribution, consultez les lignes directrices pour les commiteurs.

## Sommaire

- Travaillez avec GitHub si vous le pouvez.
- Annoncez votre travail sur le ticket Trac en y ajoutant un lien vers votre branche GitHub.
- Lorsque vous avez du code qui vous semble prêt, créez une requête de contribution (« pull request »).
- Préparez vos requêtes de contribution aussi bien que vous le pouvez.
- Lorsque vous appliquez des corrections à votre travail, utilisez `git rebase -i` pour fusionner vos commits.
- Lorsque le code principal amont a changé, faites `git fetch upstream; git rebase`.