Git rebase upstream

J’adore la fonction fork de Github. Elle me permet en un clic de cloner un projet et le rendre disponible sous mon compte. Je peux alors le modifier à ma guise, commiter et pusher mon code dans mon coin. Cerise sur le gâteau, je peux également proposer mes contributions au projet original – on parle ici d’upstream toujours en un clic grâce aux pull requests. Évidemment, il n’y a pas besoin de Github pour forker un projet dès lors qu’on a accès aux sources ; je peux également le faire manuellement, mais je dois gérer moi-même les droits sur le dépôt, et je ne profite pas des pull requests.

Le problème quand on travaille sur un fork d’un autre projet, c’est qu’on aimerait bien rester à jour par rapport à l’upstream, histoire de profiter des nouvelles fonctionnalités et des correctifs apportés par les autres développeurs.

C’est là que les bienfaits de la nature distribuée de Git interviennent. Contrairement aux gestionnaires de sources centralisés comme SCCS (j’ai travaillé dessus, je suis vieux), CVS ou SVN, Git permet de faire pointer son dépôt local sur n’importe quel dépôt distant histoire de récupérer le travail de ses petits camarades.

Explication par l’exemple.

En ce moment, je travaille pas mal avec Ansible, et notamment avec les modules EC2. Ces derniers ne supportant pas toute l’API exposée par Boto, j’ai eu besoin de les compléter.

Pour cela, j’ai commencé par forker le dépot d’Ansible sur le compte de Botify Labs, avant de le cloner localement.

$ git clone git@github.com:botify-labs/ansible.git

J’ai modifié du code (dans une branche, toujours), commité et pushé mon travail, avant de créer une pull request afin de voir mes modifications prises en compte par les développeurs d’Ansible. En attendant, j’ai installé ma version d’Ansible sur ma machine histoire de pouvoir exécuter mes playbooks en profitant des modifications.

Quelques jours plus tard, Ansible a sorti sa version 1.6. Cette version apporte quelques correctifs aux modules EC2 dont j’aimerais bien profiter tout de suite. Si j’avais utilisé un gestionnaire de sources centralisé, ça aurait été un véritable cauchemar, mais avec Git, c’est tout simple.

J’ai commencé par ajouter une nouvelle source depuis de laquelle récupérer le code de mon projet. Je pointe sur le dépôt principal du projet Ansible.

J’ai ensuite téléchargé les sources de ce dépôt afin de travailler dessus. Comme Git est vraiment bien fait, cela n’interfère en rien avec mon dépôt local.

C’est là qu’est intervenue la merveilleuse commande Git rebase, qui permet de rejouer l’ensemble des commits ajoutés à upstreams qui pourraient manquer localement. Comme je travaille sur la branche devel, je vais évidemment appliquer le rebase depuis la branche devel d’upstream.

Enfin, j’ai pushé l es modifications locales sur mon dépôt distant, non sans m’être assuré que j’étais bien à jour.

$ git pull
$ git remote add upstream git@github.com:ansible/ansible.git
$ git fetch upstream
$ git rebase upstream/devel
$ git push origin devel

Et voilà, That’s all folks comme ils disaient à la fin des dessins animés de mon enfance d’avant le Club Dorothée. La prochaine fois, je vous expliquerai comment réécrire l’Histoire encore mieux que les ministres de l’information de l’URSS l’ont jamais rêvé.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: