C'est marrant mais pour moi tes 2 exemples sont 2 extrêmes qui ne sont pas bons et qui montrent que beaucoup de gens n'ont pas compris la valeur de l'historique.
Pour moi, la meilleure façon de faire est entre les deux, même si je suis d'accord avec toi que cela est à adapter en fonction du contexte...
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.
Je vois 2 raisons qui pourrait pousser à faire ce choix:
- ils n'ont pas encore adapté leur workflow avec ce que permettent de faire maintenant les DVCS (ou n'en utilisent pas encore)
- comme c'est un projet opensource et qu'il est plus difficile "d'imposer" une façon de faire, ils préfèrent tout squasher pour éviter d'avoir à faire du babysitting en demandant systématiquement aux contributeurs de le faire (mais ils se privent d'avoir une feature construite par étape...)
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.
Je pense que cela est dû soit à une mauvaise maitrise de git soit au fait qu'ils ont décidé de faire du travail de porc et de se foutre de l'historique (ils en ont pas encore compris la valeur)
En tout cas, dans les 2 cas, leur historique n'est surement pas optimal...
[^] # Re: Pourquoi ?
Posté par cosmocat . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 2.
C'est marrant mais pour moi tes 2 exemples sont 2 extrêmes qui ne sont pas bons et qui montrent que beaucoup de gens n'ont pas compris la valeur de l'historique.
Pour moi, la meilleure façon de faire est entre les deux, même si je suis d'accord avec toi que cela est à adapter en fonction du contexte...
Je vois 2 raisons qui pourrait pousser à faire ce choix:
- ils n'ont pas encore adapté leur workflow avec ce que permettent de faire maintenant les DVCS (ou n'en utilisent pas encore)
- comme c'est un projet opensource et qu'il est plus difficile "d'imposer" une façon de faire, ils préfèrent tout squasher pour éviter d'avoir à faire du babysitting en demandant systématiquement aux contributeurs de le faire (mais ils se privent d'avoir une feature construite par étape...)
Je pense que cela est dû soit à une mauvaise maitrise de git soit au fait qu'ils ont décidé de faire du travail de porc et de se foutre de l'historique (ils en ont pas encore compris la valeur)
En tout cas, dans les 2 cas, leur historique n'est surement pas optimal...