GitHub: comment le contributeur récupère sa pull-request une fois qu'elle est mergée ?

Bonjour.

Le titre n’est certainement pas complètement clair, je vais donc détailler un peu.

Imaginons, je souhaite contribuer à un projet sur GitHub (ou autre). Donc:

1. je forke le dépôt auquel je souhaite contribuer
2. je crée une branche dev pour mes développements
3. je crée une branche feature pour ma nouvelle fonctionnalité
4. je code la nouvelle fonctionnalité
5. je fais une pull-request
6. la pull-request est acceptée

Ce que je souhaite faire, c’est merger la branche feature dans ma branche dev, parce que disons que j’ai besoin de cette fonctionnalité pour une autre fonctionnalité, ou bien que je n’ai pas le temps d’attendre que la pull-request soit acceptée.

Maintenant, la question que je me pose, c’est que se passe-t-il pour mon fork lorsque ma pull-request est acceptée ? La pull-request est intégrée à la branche principale du dépôt initial, et j’ai défini l’upstream de mon dépôt forké sur ce dépôt initial. Je vais donc récupérer des commits que j’ai déjà mergé dans ma branche dev !

Je ne sais pas si tout ceci est très clair, mais j’espère que vous comprenez la question que je soulève. Du coup: comment gère-t-on ce genre de situation ?

Je profite de ce sujet pour poser une autre question. Imaginons que mon développement sur ma branche feature prenne du temps. Pendant ce temps, de nouveaux commits apparaissent sur l’upstream. Très bien, je peux facilement les récupérer sur ma branche master, sur ma branche dev (dois-je les récupérer sur ces deux branches ?). Mais comment puis-les récupérer sur ma branche feature ? De la même façon, lorsque je mergerai ma branche feature dans ma branche dev, ces commits seront présents deux fois ! Comment gère-t-on cette autre situation ?

Etonnamment, après une rapide recherche à l’aide de mon moteur de recherche favori, je n’ai pas vraiment trouvé de réponse à ces questions…

Merci d’éclairer ma lanterne !

Salut,

Les deux questions ont la même réponse : git fait un three-way merge. Lorsque tu merges deux branches, il regarde seulement les deux extrémités des branches et leur ancêtre commun le plus jeune. Donc tu ne merges forcément que les choses nouvelles.

Je peux donc merger/rebaser à foison (façon de parler, hein ! :lol:) sans m’inquiéter des commits qui viendront de l’upstream ?

Surtout rebaser, oui.

Dans un cas classique où tu travailles sur origin/feature-foo basée sur upstream/master, tu vas régulièrement faire git fetch upstream suivi de git rebase upstream/master. (Tes commits sur origin/feature-foo resteront "au dessus" de upstream/master. On dit d’ailleurs rebase on top of upstream/master.)

C’est facile à retenir une fois que tu comprends le modèle de git. Tu as basé ta branche sur le dernier commit C de la branche B. La branche B a évolué entre-temps et a un nouveau commit C1. Tu veux que ta banche, que tu avais basée sur C, soit désormais basée sur C1. Tu dois donc "rebaser" ta branche. Pour t’éviter de devoir retenir ou copier-coller le SHA de C ou C1, tu rebases directement sur la branche en question (c’est à dire sur dernier commit que tu as en local pour cette branche B, d’où la nécessité de fetch pour récupérer les trucs). Comme ça tu pourras refaire exactement la même opération si un commit C2 y apparait.

Surtout rebaser, oui.

Juste une note de prudence là-dessus. Si tu rebases ce que tu as fait dans ton coin comme l’indique @cepus, c’est bon, mais si tu rebases des branches qui sont passées sur le serveur distant entre-temps (et ont pu être modifiées par d’autres personnes), c’est la porte ouverte aux conflits à la con parce que tu va effectivement te retrouver avec des commits qui font la même chose mais qui n’auront pas le même numéro de commit (et seront donc considérés comme deux commits différents par git).

Par contre merger, comme ça n’affecte absolument pas l’information déjà présente mais ne fait qu’en ajouter de la nouvelle, tu peux effectivement le faire à foison sans aucun risque (à part celui de te retrouver avec un historique imbitable).

Surtout rebaser, oui.

Toujours pour rajouter une note de prudence, si tu rebases sans retester les commits un par un, tu ne sais pas si le rebase a introduit une régression contrairement à un merge, la façon SVN est bien mais demande quand même un peu d’effort au moins avant un merge pour être efficace.

Aussi, tu voudras probablement utiliser un rebase --onto plutôt qu’un rebase classique pour ça, sinon tes commits pourraient être dupliqués. Un commit c’est en très rapide un état de ton dépôt et un ancêtre donc si l’ancêtre change le commit change.

La réponse à la question d’avant c’est aussi : un fork, ça demande du temps à maintenir pour tenir à jour par rapport au dépôt initial. Idéalement tu peux faire merger toutes les features que tu veux, avoir une branche dev pour proposer tes features, puis garder une branche master qui les récupère depuis le dépôt principal. Tes branches features se basent sur master mais tu récupères les commits (via cherry-pick ou merge) dans dev. Régulièrement, quand tes features sont mergées, tu peux remettre dev à l’état de master.