Suport technique et veille technologique

Bidouilleux d’Web  -  Ma méthode de travail avec Git et GitHub

 -  Avril 2016 - 

Cet article est une traduction de Documenting my git/GitHub worklow écrit par Karl Dubost. Karl participe au projet WebCompat pour veiller à ce que les sites web fonctionnent de façon égale sur les différents navigateurs et ce billet est l’occasion de présenter la méthode de travail qu’il utilise avec Git et GitHub. Les méthodes vues ici pourront être utile pour contribuer à d’autres projets, n’hésitez pas à guetter les fichiers CONTRIBUTING.md des différents dépôts. ;)

Dans le cadre de webcompat.com, nous développons le projet à l’aide, entre autres, de l’infrastructure offerte par GitHub. Nous avons ainsi un dépôt webcompat.com. N’hésitez pas à contribuer.

Je ne suis pas certain de suivre la même méthode que les contributeurs principaux, mais j’ai pensé que ce serait utile de documenter la façon dont je contribue. Cet article pourra aider les débutants voire m’être utile à l’avenir.

Commençons avec un rapide brouillon.

Le projet est hébergé sur : https://github.com/webcompat/webcompat.com/

Pour commencer je crée un fork (N.D.T. d’aucuns pourront utiliser « fourche ») grâce au bouton situé en haut à droite du site.

Ce fork est désormais créé :

https://github.com/karlcow/webcompat.com/

Désormais, je peux créer un clone local de ce dépôt sur mon ordinateur grâce à la commande suivante :

git clone git@github.com:karlcow/webcompat.com.git

Je clone ce fork plutôt que le projet original afin de pouvoir travailler en local et bidouiller différentes branches, les envoyer vers GitHub sur mon fork sans risquer de gêner qui que ce soit. Quand je souhaite mêler mon code à celui des autres, j’envoie alors des pull requests vers le dépôt principal.

Une fois que c’est fait, je dispose d’une version à date du dépôt et je peux commencer à travailler sur une issue. Prenons par exemple l’issue 902 (simplement pour l’exemple). Je crée une nouvelle branche sur mon clone local (voir la section suivante pour la mise à jour de mon fork local).

git checkout -b 902/1

Pour nommer les branches, j’ai « emprunté » le protocole de Mike :

nom_de_branche  = numéro_issue/version_de_branche

Ainsi, lorsque je ne suis pas satisfait de mon travail, mais que je souhaite conserver un certain historique, je peux créer une deuxième branche pour la même issue avec la commande git checkout --b 902/2 et ainsi de suite. Une fois satisfait, je peux choisir d’envoyer une pull request depuis la meilleure branche.

git commit -m ’#902 upgrade GitHub-Flask to 3.1.1’ 
requirements.txt
git commit -m ’#902 upgrade Flask-Limiter to 2.2.0’
requirements.txt
# etc

Une fois la journée finie, quand je souhaite passer à autre chose ou simplement partager le code, j’envoie le contenu de mon dépôt local vers mon fork hébergé sur GitHub.

git push karlcow 902/1

Vous aurez remarqué que je n’ai pas utilisé git push origin 902/1, j’explique après la façon dont j’utilise des alias pour les dépôts.

Une fois mes commits terminés, je peux créer une pull request depuis karlcow:902/1 vers webcompat:master :

https://github.com/webcompat/webcompat.com/pull/920

J’utilise ce message :

fix #902 - 902/1 Update python module dependencies in the project.

et demande à Mike d’effectuer la revue du code

r? @miketaylr

Ensuite, nous discutons, rejetons la modification, la modifions ou la fusionnons.

Les alias de dépôt

Généralement, GitHub utilise les termes suivants :

• upstream pour désigner le dépôt original
• origin pour désigner votre propre fork

Cela était source de confusion et j’ai donc choisi une autre approche :

git remote rename origin karlcow
git remote rename upstream webcompat

Cela devient beaucoup plus simple lorsque je mets à jour le projet ou que je pousse mes commits. Je sais exactement où ils vont.

# On télécharge des choses depuis le dépôt webcompat.com sur github.com
git fetch webcompat
# Je pousse ma branche vers mon propre fork sur github.com
git push karlcow nom_branche

Mettre à jour mon fork local

À chaque fois, lorsque j’ai terminé de travailler sur une branche ou que j’ai fini ma session de travail et que tous les commits ont été effectués, je synchronise la branche master de mon clone (local) avec la branche master de webcompat.com Voici le vocabulaire GitHub que j’utilise généralement :

git checkout master
git fetch upstream
git merge upstream/master

Transposé avec mes alias, cela donne :

git checkout master
git fetch webcompat
git merge webcompat/master

Mon projet est désormais à jour et je peux créer une nouvelle branche pour la prochaine issue sur laquelle je travaillerai.

Faire le ménage entre les forks locaux et distants

Je crée des branches locales sur ~/code/webcompat.com et des branches distantes sur https://github.com/karlcow/webcompat.com/, mieux vaut les supprimer au fur et à mesure pour éviter d’avoir une énorme liste de branches avec :

git branch -a

Par exemple, si je la lance maintenant, voici le résultat que j’obtiens :

git branch -a
  264/1
  396/1
* 710/3
  713/1
  master
  r929/958
  remotes/karlcow/264/1
  remotes/karlcow/702/1
  remotes/karlcow/710/1
  remotes/karlcow/710/3
  remotes/karlcow/HEAD -> karlcow/master
  remotes/karlcow/master
  remotes/webcompat/gh-pages
  remotes/webcompat/issues/741/2
  remotes/webcompat/letmespamyou
  remotes/webcompat/master
  remotes/webcompat/searchwork
  remotes/webcompat/staging
  remotes/webcompat/staticlabels
  remotes/webcompat/webpack

Pour faire le ménage, j’utiliserai les commandes suivantes :

#  Suppression locale (sur l’ordinateur)
git branch -d 12/1 245/1

# Suppression distante (sur mon dépôt GitHub)
git push karlcow --delete 12/1
git push karlcow --delete 245/1

Otsukare !

Merci Karl d’avoir permis cette traduction !

par sphinx