Mais bon avoir des commits propres c'est pas un objectif en sois, ça peut juste être un choix de méthode de travail pour une communauté donnée.
Ça devrait être un objectif, du moins si on souhaite travailler à plusieurs sur le dit projet.
De ce que raconte l'auteur, son workflow ne peut fonctionner que parce qu'il est seul à bosser dessus (et cela se vérifie sur GitHub). Avec un tel workflow, il est impossible de travailler à plusieurs. Continuer ainsi ne va pas aider à attirer des contributeur.
Car bon, utiliser des commits pour sauvegarder son travail, c'est bien, mais dans une branche personnelle. Certainement pas en master.
Comment cela se passerait s'ils sont plusieurs à procéder ainsi ? Il y aura des conflits de partout et chacun va perdre du temps pour tester sa modification car l'autre aura poussé un truc sale qui peut ne pas compiler ou fonctionner.
Cela n'aide pas non plus pour si jamais quelqu'un reprend le flambeau. Les commits doivent avoir un sens, être le plus unitaire possible avec un message plutôt explicite. Cela n'empêche pas de documenter les choses autre part et autrement, mais qu'au moins les données récoltées via Git soient exploitables.
Des workflow git, il y a en a plein qui sont viables. Mais je n'en connais aucun exploitable en travail en équipe où master est une branche unique où chacun pousse ce qu'il veut dessus. Le minimum est d'avoir une branche master et une autre consacrée à un développement (la future version, une fonctionnalité particulière ou une branche personnelle).
En plus honnêtement, cela ne prendrait pas vraiment plus de temps de mettre ça en place (créer une branche et rebaser de temps en temps celle de développement sur master, cela est rapide). Par contre le gain serait énorme, pour d'éventuels contributeurs externes, mais je pense aussi pour l'auteur lui même.
[^] # Re: Grosse flemme ou autre(s) raison(s) ?
Posté par Renault (site web personnel) . En réponse à la dépêche G’MIC 2.0 : un second souffle pour le traitement d’images libre. Évalué à 6.
Ça devrait être un objectif, du moins si on souhaite travailler à plusieurs sur le dit projet.
De ce que raconte l'auteur, son workflow ne peut fonctionner que parce qu'il est seul à bosser dessus (et cela se vérifie sur GitHub). Avec un tel workflow, il est impossible de travailler à plusieurs. Continuer ainsi ne va pas aider à attirer des contributeur.
Car bon, utiliser des commits pour sauvegarder son travail, c'est bien, mais dans une branche personnelle. Certainement pas en master.
Comment cela se passerait s'ils sont plusieurs à procéder ainsi ? Il y aura des conflits de partout et chacun va perdre du temps pour tester sa modification car l'autre aura poussé un truc sale qui peut ne pas compiler ou fonctionner.
Cela n'aide pas non plus pour si jamais quelqu'un reprend le flambeau. Les commits doivent avoir un sens, être le plus unitaire possible avec un message plutôt explicite. Cela n'empêche pas de documenter les choses autre part et autrement, mais qu'au moins les données récoltées via Git soient exploitables.
Des workflow git, il y a en a plein qui sont viables. Mais je n'en connais aucun exploitable en travail en équipe où master est une branche unique où chacun pousse ce qu'il veut dessus. Le minimum est d'avoir une branche master et une autre consacrée à un développement (la future version, une fonctionnalité particulière ou une branche personnelle).
En plus honnêtement, cela ne prendrait pas vraiment plus de temps de mettre ça en place (créer une branche et rebaser de temps en temps celle de développement sur master, cela est rapide). Par contre le gain serait énorme, pour d'éventuels contributeurs externes, mais je pense aussi pour l'auteur lui même.