est-il préférable d'avoir tout le détail du code dans un arbre unique, avec tous les micro-commits, mais au moins on garde tout, pour toujours, et on peut tout retrouver
Tu peux faire un entre-deux, comme pour le noyau : le code intégré doit être formaté et séparé comme il faut, en commits ni trop gros ni étant des commit « de travail » (genre du « fix that », « update » ou « work in progress »). Les branches des devs sont retravaillées (rebasée) jusqu'à avoir une tête correcte pour pouvoir être mergée sans avoir les détails de comment le travail a été fait, mais plutôt le détail de la signification d'ensemble cohérents (genre on sépare le cœur d'une feature de son activation dans le reste du code). Toutes cette préparation est effectuée par échange de mails sur la LKML en ce qui concerne Linux.
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par benoar . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 7. Dernière modification le 19 septembre 2018 à 10:25.
Tu peux faire un entre-deux, comme pour le noyau : le code intégré doit être formaté et séparé comme il faut, en commits ni trop gros ni étant des commit « de travail » (genre du « fix that », « update » ou « work in progress »). Les branches des devs sont retravaillées (rebasée) jusqu'à avoir une tête correcte pour pouvoir être mergée sans avoir les détails de comment le travail a été fait, mais plutôt le détail de la signification d'ensemble cohérents (genre on sépare le cœur d'une feature de son activation dans le reste du code). Toutes cette préparation est effectuée par échange de mails sur la LKML en ce qui concerne Linux.