Nous souhaitons déposer des cookies à des fins de mesure d'audience avec Google Analytics. Vous êtes libre d'accepter ou de refuser. En poursuivant votre navigation sur ce site sans exprimer votre choix, vous autorisez la mesure d'audience.
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
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 :
créer une branche bugfixes où tu corriges plusieurs petits bugs ;
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
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"
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
Vous devez être connecté pour pouvoir poster un message.
Connexion
Pas encore inscrit ?
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
