Si tu dois retrouver un bug ou relire le code, je préfère largement lire plusieurs petits commits ayant du sens plutôt qu'un seul gros commit où ton cerveau aura beaucoup (trop?) d'informations à traiter...
C'était une vraie question qui n'attend pas de réponse unique. Elle doit être adaptée au contexte et est forcément subjective. De ce choix découle la façon de travailler tes commits et ton historique.
Tu as énormément de gros projets qui travaillent avec des historiques très plats car le point d'intégration est un patch (ou patch set) qui est soumis, relu et accepté. C'est par exemple le fonctionnement des projets Apache.
A l'inverse la plupart des projets préfèrent merger 50 commits même non travaillés. C'est aussi ce que tu vois le plus en entreprise.
[^] # Re: Pourquoi ?
Posté par ckyl . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 6.
C'était une vraie question qui n'attend pas de réponse unique. Elle doit être adaptée au contexte et est forcément subjective. De ce choix découle la façon de travailler tes commits et ton historique.
Tu as énormément de gros projets qui travaillent avec des historiques très plats car le point d'intégration est un patch (ou patch set) qui est soumis, relu et accepté. C'est par exemple le fonctionnement des projets Apache.
A l'inverse la plupart des projets préfèrent merger 50 commits même non travaillés. C'est aussi ce que tu vois le plus en entreprise.
Chacun a ses propriétés.