Hum… je ne suis pas vraiment d’accord.

> faire une bouillie de commit linéaire et virtuels.

Et pourtant, ne pas se soucier de l’historique crée en général une bouillie de commits souvent illisibles et pouvant poser de vrais gros problèmes le jour où une régression existe et n’est pas détectée par des processus d’intégration continue ou autre (ce n’est pas toujours possible).

Avoir un joli historique est en général le signe d’un soucis de qualité. Et pour avoir déjà réussi à passer de l’ordre de 2 jours à naviguer dans un historique absolument illisible à la recherche d’un commit provoquant une régression, j’ai du mal à me dire que c’est juste un problème d’usage d’outil de visualisation.

Si on est capable d’avoir CI + octopus merge alors ça peut en effet être intéressant et je suis d’accord que dans ce cas on peut oublier squash/rebase.

En exemple voici ce que j’avais mis en place comme workflow, justement à base de rebase avant merge (le squash avait été évoqué même si on ne l’a pas mis en place) : http://blog.sogilis.com/post/104148375576/notre-workflow-git-pourquoi-comment