Lorsque tu merge, git regarde le plus récent ancêtre commun aux deux branches pour calculer un patch. C'est central de bien avoir conscience des conséquences pour construire un workflow. La règle : trouver l'ancêtre, puis depuis l'ancêtre merger la branche qui a le plus de commit vers celle qui en a le moins (si 0 => garantie sans conflit).
Si tu travailles avec l'intention de merger dans work il faut que tu fasses partir tes branches temp de work, pas de main. C'est ton erreur.
Et il faut que toutes tes temp soient indépendantes en terme de couverture de code modifié (sinon mauvaise archi et/ou mauvaise gestion projet). Tu te retrouves avec un workflow de type : temp = test unitaire (par feature), work = tests d'intégration (pas d'effets de bords entre les features), main = production. Si tu dois faire de la maintenance prod : tu sors une branche de main, tu testes, tu merges dans main, puis tu redescend ta prod en merge de main vers work, puis (éventuellement) de work vers tes temp (propagation du correctif). Pourquoi faire dans ce sens ? Parce que tu aura tes éventuels conflits à la descente vers ta hors-prod ; tu les résoud ; tu restes (non rég sur le correctif de maintenance, développements qui ne cassent pas : ces tests sont indispensables même en l'absence de conflits1) ; puis tu remontes en prod tes nouvelles features avec l'assurance de n'avoir aucun conflit.
Sinon tu as plein de propal' de workflow sur Internet. Essaies de voir avec ton collègue ce qui conviendrait le mieux. Un petit conseil : allez au plus simple... car ce qu'on trouve souvent c'est overkill (s'adresse à de grosses équipes de dev).
Là déjà vous avez un workflow assez costaud pour une équipe de deux.
1 car deux développements peuvent se révéler incompatibles alors qu'ils ne modifient pas les mêmes lignes de code.
# Effectivement mauvais workflow
Posté par Nicolas (site web personnel) . En réponse au message Git - Rebase - Conflits - Worflow ?. Évalué à 7.
Lorsque tu merge, git regarde le plus récent ancêtre commun aux deux branches pour calculer un patch. C'est central de bien avoir conscience des conséquences pour construire un workflow. La règle : trouver l'ancêtre, puis depuis l'ancêtre merger la branche qui a le plus de commit vers celle qui en a le moins (si 0 => garantie sans conflit).
Si tu travailles avec l'intention de merger dans work il faut que tu fasses partir tes branches temp de work, pas de main. C'est ton erreur.
Et il faut que toutes tes temp soient indépendantes en terme de couverture de code modifié (sinon mauvaise archi et/ou mauvaise gestion projet). Tu te retrouves avec un workflow de type : temp = test unitaire (par feature), work = tests d'intégration (pas d'effets de bords entre les features), main = production. Si tu dois faire de la maintenance prod : tu sors une branche de main, tu testes, tu merges dans main, puis tu redescend ta prod en merge de main vers work, puis (éventuellement) de work vers tes temp (propagation du correctif). Pourquoi faire dans ce sens ? Parce que tu aura tes éventuels conflits à la descente vers ta hors-prod ; tu les résoud ; tu restes (non rég sur le correctif de maintenance, développements qui ne cassent pas : ces tests sont indispensables même en l'absence de conflits1) ; puis tu remontes en prod tes nouvelles features avec l'assurance de n'avoir aucun conflit.
Sinon tu as plein de propal' de workflow sur Internet. Essaies de voir avec ton collègue ce qui conviendrait le mieux. Un petit conseil : allez au plus simple... car ce qu'on trouve souvent c'est overkill (s'adresse à de grosses équipes de dev).
Là déjà vous avez un workflow assez costaud pour une équipe de deux.
1 car deux développements peuvent se révéler incompatibles alors qu'ils ne modifient pas les mêmes lignes de code.