Comment faire une branche de "bugfixes"

Le problème exposé dans ce sujet a été résolu.

Bonjour,

On m’a conseillé :

Pour ton problème d’atomicité, mon conseil serait de te faire une branche de "bugfixes" avec un commit par bug, et ensuite de découper en PRs séparées (pour chaque commit ou grappes de commit, tu recrées une branche à partir de trunk et tu cherry-pick le(s) commit(s) en question). Tu peux continuer à corriger dans ta branches "bugfixes" (qui n’est jamais soumise en tant que telle) pendant que les PRs sont gérées.

Donc :

  • Pour créer cette branch par commit git branch coloronly bcd2a73ad4c5588d2335604d2b96a2a9404f9ced

Ensuite j’ai :

git push origin
fatal: La branche courante coloronly n'a pas de branche amont.
Pour pousser la branche courante et définir la distante comme amont, utilisez

    git push --set-upstream origin coloronly

Est-ce normal ?

Mais au final je me retrouve avec deux commits : https://github.com/zestedesavoir/zds-site/pull/5129

+0 -0

Est-ce normal ?

Oui, lors du premier git push, il faut dire sur quelle remote tu envoies ta branche avec git push -u <remote> <branch>. Ce qui donne pour toi git push -u origin coloronly :)

Ce qui t’a été conseillé c’est :

  1. créer une branche bugfixes où tu corriges plusieurs petits bugs ;
  2. pour chaque bug, créer une branche à part (qu’on peut nommer fix-xxxx s’il y a un ticket correspondant) et récupérer le commit qui répare le bug pour pouvoir faire une PR.

Je ne sais pas si c’est une bonne pratique ou pas.

Créer la branche bugfixes :

# On part sur de bonnes bases
git fetch upstream/dev
git checkout upstream/dev

# On crée la branche 'bugfixes'
git checkout -b bugfixes

# Tu peux maintenant faire tes modifications
# Tu n'es pas obligé d'envoyer la branche sur Github

Quand tu veux créer une PR pour une modification :

# S'il y a eu des changements sur 'upstream/dev' entre temps
git fetch upstream/dev

git checkout bugfixes
# On récupère l'identifiant du commit qui corrige le bug
git log

git checkout upstream/dev
git checkout -b fix-xxxx # Remplacer 'xxxx' par le numéro du ticket ou choisir un autre nom
# On récupère le commit
git cherry-pick <identifiant du commit>

# On envoie tout ça
git push -u origin fix-xxxx

# Tu peux faire ta PR
+0 -0

Oups !

J’ai fais :

git cherry-pick <identifiant du commit>
git cherry-pick continue

Mais je devais faire quel commande entre les deux pour choisir la bonne version ?

EDIT : Ca ne semble pas être une bonne pratique car là j’ai l’impression qu’il mélange un peu tout, car normalement j’ajoute juste "installed" dans ce commit ! Le sujet initial est ici : https://github.com/zestedesavoir/zds-site/issues/5100#issuecomment-438032608

+0 -0

Lorsque Git a essayé d’appliquer les changements contenus dans ton commit, il y a eu un conflit. Git ne sait pas quoi choisir entre les deux versions. Il faut donc que tu édites le fichier en question, puis que tu fasses git add <fichier> avant de continuer l’opération "cherry-pick" :)

+0 -0

Si tu as deux bugfixes qui sont liés, le plus simple est de garder les commits ensemble au lieu d’essayer de les séparer. Tu fais une branche pour le premier groupe de commits, tu peux envoyer ça comme PR, et ensuite tu fais une branche pour le second groupe au-dessus de la branche du premier. Tu peux encore envoyer ça comme PR, en précisant que les commits du premier groupes viennent de l’autre PR et qu’ils seront sans doute intégrés avant.

C’est ce que j’ai fait pour #5084, dont le premier message précise bien qu’elle est par dessus #5083.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte