29-09-2021, 11:26:25
Je pense qu'à l'avenir, faudra qu'on crée un compte "primtux" ou tous les devs importants (ex: Philippe, Cyril, Toi et moi) ont les droits et ou se trouve tous les dépôts de référence.
Parce que, je parts du principe pour les "handymenu" que la branche "master" sur ton dépôt représente LA référence, en somme la prod.
Je me synchronise régulièrement dessus (mon master se retrouve au même niveau que le tient et non l'inverse), aussi pour te simplifier la vie côté git (même si j'ai des ratés : en règle général, quand il y a des conflits)
Si ma branche master est cassé (ce qui n'arrive en réalité pas car elle ne bouge jamais en local), c'est pas un soucis : je me remet iso à la référence.
Le compte ou l'on soumet des demandes de merge (https://framagit.org/Steph/handymenu-primtux) est la référence. Si tu as une modif à apporter, tu l'as demande sur ton propre dépôt.
Sinon, on s'en sortira pas.
Si t'es sur de ton coup, tu merges direct : sinon, n'hésites pas à me soumettre la relecture (la review de code évite une grande partie des erreurs d'étourderie).
Si je te soumets des merge request (et que je merge pas moi même) c'est pour t'habituer à ce workflow.
Pour rappel : idéalement, sur tout projet Git on a des fonctionnalités, des correctifs et des montées de versions.
Pour chaque besoin, on crée une branche.
Tu as du le voir :
- si c'est une fonctionnalité, elle se nomme "feature/le_descriptif_de_ma_fonctionnalité"
- si c'est un correctif, elle se nomme "bugfix/le_descriptif_de_mon_bug"
- si c'est une version, elle se nomme "version/le_nom_de_la_version"
En toute logique, on passe un ensemble de fonctionnalités et de bugs et quand nos tests sont concluant, on fige ça avec une version (qui va éditer le debian/changelog).
Parce que, je parts du principe pour les "handymenu" que la branche "master" sur ton dépôt représente LA référence, en somme la prod.
Je me synchronise régulièrement dessus (mon master se retrouve au même niveau que le tient et non l'inverse), aussi pour te simplifier la vie côté git (même si j'ai des ratés : en règle général, quand il y a des conflits)
Si ma branche master est cassé (ce qui n'arrive en réalité pas car elle ne bouge jamais en local), c'est pas un soucis : je me remet iso à la référence.
Le compte ou l'on soumet des demandes de merge (https://framagit.org/Steph/handymenu-primtux) est la référence. Si tu as une modif à apporter, tu l'as demande sur ton propre dépôt.
Sinon, on s'en sortira pas.
Si t'es sur de ton coup, tu merges direct : sinon, n'hésites pas à me soumettre la relecture (la review de code évite une grande partie des erreurs d'étourderie).
Si je te soumets des merge request (et que je merge pas moi même) c'est pour t'habituer à ce workflow.
Pour rappel : idéalement, sur tout projet Git on a des fonctionnalités, des correctifs et des montées de versions.
Pour chaque besoin, on crée une branche.
Tu as du le voir :
- si c'est une fonctionnalité, elle se nomme "feature/le_descriptif_de_ma_fonctionnalité"
- si c'est un correctif, elle se nomme "bugfix/le_descriptif_de_mon_bug"
- si c'est une version, elle se nomme "version/le_nom_de_la_version"
En toute logique, on passe un ensemble de fonctionnalités et de bugs et quand nos tests sont concluant, on fige ça avec une version (qui va éditer le debian/changelog).