Workflow pour Github

Branches

Nous travaillons avec des branches !

  1. En cliquant sur le bouton “Fork” dans un dépôt Github, forkez le dépôt sur lequel vous souhaitez travailler :

  2. Clonez votre dépôt dans votre environnement de travail :

    git clone git@github.com:UTILISATEUR/DÉPÔT -o UTILISATEUR
    • UTILISATEUR est votre nom d’utilisateur sur Github.
    • DÉPÔT est le nom du dépôt sur lequel vous souhaitez travailler.

    Nous utilisons -o UTILISATEUR pour être sûr que nous ne pushons pas origin vers le dépôt principal par mégarde dans le futur.

  3. Ajoutez le dépôt principal :

    git remote add spip git@github.com:spip/DÉPÔT
  4. Créez une nouvelle branche :

    git checkout -b BRANCHE

    Ne travaillez jamais sur master ! Créez toujours une nouvelle branche pour quoi que ce soit.

  5. Amusez‑vous bien !

Noms de branche

Utilisez des noms de branche courts et descriptifs de ce qui justifie le travail dans cette branche. Habituellement, pas plus de deux ou trois mots.

Travaillez ensemble !

Vous pourriez tomber malade, or worse, enlevé par des extra‑terrestres. Quelque soit le cas, vous devriez pusher votre travail à la fin de la journée !, afin que quelqu’un puisse prendre le relais si nécessaire :

git push UTILISATEUR BRANCHE

Assurez‑vous que vous pushez votre travail sur votre propre fork.

Pull Requests

En tant que personne qui ouvre la PR

Une fois que votre travail vous convient, vous pouvez proposer une PR. Assurez‑vous :

  1. d’ajouter une description à votre PR.

Les Pull Requests sont proposées de votre fork à un autre dépôt (spip, marcimat, etc.).

Des membres de Spip en feront ensuite une revue.

Si aucun commentaire ne relève de problème et que la PR reçoit deux validations, la PR peut être mergée.

Vous êtes responsable de votre PR, donc vous êtes en charge de pousser à ce qu’elle soit mergée et vous décidez de quand votre PR sera mergée, (tant que ça n’est pas trop tôt).

En bref

  1. Codez quelque chose d’utile et propre.
  1. [Proposez une Pull Request].
  2. Demandez une revue de code via @utilisateur ou @team dans la description ou le premier commentaire.
  3. Ces personnes feront une revue de la PR.
  4. Ces personnes laisseront des commentaires que vous devrez traiter (Défendez votre code !).
  5. Une fois tous les commentaires traités, vous recevez deux approbations (ou votre PR est close et vous pouvez passer les étapes suivantes).
  6. Selon les besoins, la PR peut être mergée ou des tests plus conséquents auront lieu.
  7. Demandez à ce que quelqu’un merge votre PR (ou faites‑le vous‑même si vous avez les autorisations).
  8. Champagne !

En tant que personne travaillant sur une tâche secondaire

Lorsque plusieurs personnes travaillent sur plusieurs tâches secondaires, elles feront des PR sur une branche commune. Cette branche sera ensuite mergée avec master.

Si, par exemple, nous avons une tâche principale pour l’implémentation de « Super fonctionnalité », qui suivrait cette structure :

{
    "résumé":      "Implementer Super fonctionnalité",
    "issueID":     "JLA-100",
    "responsable": "Bruce Wayne",
    "remote":      "batman",
    "branche":     "JLA-100-super-fonctionnalite",

    "taches secondaires": [
        {
            "résumé":      "Make data available in templates",
            "issueID":     "JLA-101",
            "responsable": "Diana Prince",
            "remote":      "ww",
            "branche":     "JLA-100-super-fonctionnalite-backend"
        },
        {
            "résumé":      "Display data through templates",
            "issueID":     "JLA-102",
            "responsable": "Clark Kent",
            "remote":      "superman",
            "branche":     "JLA-100-super-fonctionnalite-frontend"
        }
    ]
}
  1. Bruce, Diana et Clark définissent ce qui doit être fait.

  2. Bruce (responsable de JLA-100) crée une branche (JLA-100-super-fonctionnalite) :

    git checkout -b JLA-100-super-fonctionnalite spip/master
  3. Bruce push sa branche vers son dépôt (batman/JLA) :

    git push -u batman JLA-100-super-fonctionnalite
  4. Diana travaille sur un fork de la branche de Bruce (JLA-100-super-fonctionnalite-backend):

    git checkout -b JLA-100-super-fonctionnalite-backend batman/JLA-100-super-fonctionnalite
  5. Diana push sa branche vers son dépôt (ww/JLA) :

    git push -u ww JLA-100-super-fonctionnalite-backend
  6. Diana proposera alors une Pull Request depuis sa branche vers la branche de Bruce.

  7. En parallèle, Clark a travaillé sur JLA-102 et a également proposé une PR vers la branche de Bruce.

  8. Bruce merge les branches de Diana et Clark vers sa branche une fois que d’accord.

  9. Bruce suit le process normal d’une PR avec JLA-100-super-fonctionnalite.