Tu trouve que tout le monde qui envoie des commit dans un même dépôt très fréquemment ça scale ? Si tu le fait avec quelques développeurs ça peut marcher, si vous êtes plus ça ne me semble pas réaliste. Ton dépôt central devient un amas de travail en cours divers et de qualité assez faible, ton historique est inutilisable,...
En quoi c'est un problème ?
Ben tu gêne tout le monde. Si tu veux lancer une analyse statique du code tu as des faux positifs, potentiellement ton code à moitié fini a des effets de bords que tu n'a pas encore imaginés ou pris en compte,... Tu augmente la charge globale de tous le monde pour prendre en compte ton travail, alors que si c'est ton travail, ce serait logique que ce soit à toi que reviens la charge d'intégrer proprement ton code. Tu gagne un historique propre. Pour gérer les gros merge, d'une part tu va naturellement avoir tendance à écrire du code moins invasif, tu ça va te pousser à communiquer avec les développeurs qui travaillent sur la même portion de code que toi (et ça c'est bien parce que c'est pas parce qu'il n'y a pas de conflit détecté par ton VCS qu'il n'y a pas de conflit entre vos travaux) et ça pousse à écrire des tests. Bref oui c'est pas forcément simple, mais ça pousse de bonnes pratiques.
Tu n'es pas obligé d'activer l'option dans le système de compilation.
Si tu as un couplage tellement fort que tu dois passer ton temps à faire des merges je doute que tu puisse le faire proprement.
D'ailleurs rien ne t'interdit de faire 300 rebase par jour pour que le jour où tu pousse tes modif' tu n'ai pas de gros merge.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 4.
Tu trouve que tout le monde qui envoie des commit dans un même dépôt très fréquemment ça scale ? Si tu le fait avec quelques développeurs ça peut marcher, si vous êtes plus ça ne me semble pas réaliste. Ton dépôt central devient un amas de travail en cours divers et de qualité assez faible, ton historique est inutilisable,...
Ben tu gêne tout le monde. Si tu veux lancer une analyse statique du code tu as des faux positifs, potentiellement ton code à moitié fini a des effets de bords que tu n'a pas encore imaginés ou pris en compte,... Tu augmente la charge globale de tous le monde pour prendre en compte ton travail, alors que si c'est ton travail, ce serait logique que ce soit à toi que reviens la charge d'intégrer proprement ton code. Tu gagne un historique propre. Pour gérer les gros merge, d'une part tu va naturellement avoir tendance à écrire du code moins invasif, tu ça va te pousser à communiquer avec les développeurs qui travaillent sur la même portion de code que toi (et ça c'est bien parce que c'est pas parce qu'il n'y a pas de conflit détecté par ton VCS qu'il n'y a pas de conflit entre vos travaux) et ça pousse à écrire des tests. Bref oui c'est pas forcément simple, mais ça pousse de bonnes pratiques.
Si tu as un couplage tellement fort que tu dois passer ton temps à faire des merges je doute que tu puisse le faire proprement.
D'ailleurs rien ne t'interdit de faire 300 rebase par jour pour que le jour où tu pousse tes modif' tu n'ai pas de gros merge.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)