Forum Programmation.autre Git - Rebase - Conflits - Worflow ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
3
16
fév.
2026

Salut,

J'essaye d'utiliser Git de la manière suivante:

Une branche main avec la version de prod.
Une branche work avec la version de dev.
Ces 2 branches sont en local et distante afin que mon collaborateur puisse tester la branche work et me donne le feu vert pour poussé vers main.
En local je fais une branche temp à partir de main, pour chaque bug que je corrige ou fonctionnalité que j'ajoute.
C'est ces branches que je fusionne dans work et si c'est ok je fusionne toujours cette même branche dans main (et souvent je supprime la branche après quelque temps).
Donc j'ai plusieurs branche en parallèle qui mette plus ou moins de temps à arriver dans main alors que je fusionne régulièrement dans work pour être testé.
Donc il m'arrive de vouloir rebase une branche temp avec main et ça se passe bien et même si il y a conflit je vois vite pourquoi et je corrige.
On arrive au problème que je rencontre souvent et qui me fait dire que je rate un concept de git. Quand je veux fusionner une branche (qui a été rebase) j'ai des conflits mais je vois bien que c'est des conflits comme si il fallait refaire des commits précédent. Je rate un truc car je me dit naïvement que git devrait voir que c'est des commit déjà existant.
Qu'est ce que vous en pensez ? Je fais quoi de travers ? Vous travaillez comment vous ?

  • # rerere

    Posté par  (site web personnel) . Évalué à 5 (+3/-0).

    T'as regardé ça https://git-scm.com/book/en/v2/Git-Tools-Rerere ?

    Matthieu Gautier|irc:starmad

  • # Branches à courte durée de vie

    Posté par  . Évalué à 6 (+4/-0).

    Hello,
    perso je fais des branches éphémères, je pense que c'est une méthode assez classique :

    nouveauté_du_lundi -> squash+merge dans main
nouveauté_du_mardi -> squash+merge dans main
nouveauté_du_mercredi -> ça prend du temps, le merge sera pour plus tard
nouveauté_du_jeudi -> squash+merge dans main
rebase de la branche main dans nouveauté_du_mercredi (on récupère ce qui était dans nouveauté_du_jeudi au passage)
nouveauté_du_mercredi -> squash+merge dans main

    On a comme habitude dans mon équipe de squash les commits intermédiaires, pour n'avoir qu'un commit par branche à la du travail, sauf si vraiment c'est utile de garder les commits séparés.

    On ne garde pas de branches séparées longtemps. Les merge dans la branche principale se font par fast-forward.

    On rebase souvent la branche principale dans les branches de dev, pour avoir le diff le plus petit par-rapport à la prod. Ceci nous oblige aussi à toujours tester notre code de dev depuis la version la plus à jour possible de la branche principale.

    Ça marche bien car on fait plutôt des petits changements, on est une petite équipe, et que les merge avec commit de merge rendent l'historique confus, on préfère rebase et fast-forward.

  • # release

    Posté par  (Mastodon) . Évalué à 5 (+2/-0).

    Si je comprends bien, ta branche "main" est en fait une branche "release", c'est à dire qu'elle a peu de commits, et chaque commit est finalement la correction de plusieurs bugs.

    Work est là où le projet est le plus avancé, donc quand tu bosses sur un bug dans une branche temporaire, je ne comprends pas pourquoi tu dois te rebaser sur "main" (qui fatalement est en retard sur "work"). Qu'y a-t-il dans "main" qui n'est pas déjà présent dans "work" ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: release

      Posté par  (site web personnel) . Évalué à 1 (+0/-0).

      Effectivement main est comme une branche release, je dirais pas qu'elle a peu de commit car elle a autant de commits qu'il y a de commits dans chaque branche temp. Donc main est une branche release mais ce n'est pas un "snapshot" de work
      Et donc oui work est la branche la plus avancée.
      Pourquoi je me base sur main pour un bug ou une fonction ? c'est parceque quand je vais merger ladite branche dans main j'ai pas envie qu'il y ait des commits venant de branches déjà dans work ?
      Oui il n'y a théoriquement rien dans main qui n'est pas dans work.

  • # Effectivement mauvais workflow

    Posté par  (site web personnel) . Évalué à 4 (+3/-0).

    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 conflits¹) ; 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.

    ¹ car deux développements peuvent se révéler incompatibles alors qu'ils ne modifient pas les mêmes lignes de code.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.