Bonjour.
Je code à mes heures perdues. Rien de bien transcendant, mais quelques petits projets perso pour m'amuser, ou pour apprendre/comprendre certaines technos.
J'utilise Git ou Mercurial pour gérer les diverses versions de mon code. Je ne partage rien, j'ai juste un repo local qui me permet de revenir en arrière lorsque je me trompe dans mon code. Pour l'instant je ne distribue pas (j'estime mon code pas assez intéressant), mais il est possible qu'un jour je le fasse.
De ce fait je me pose un certain nombre de questions à ce sujet, et peut-être que vos réponses pourraient m'aider un jour.
1/ Supposons que l'un de mes petits projets devienne intéressant pour d'autres, ou suffisamment mature pour que je me décide à le diffuser, et que d'autres personnes veuillent y participer. Comment organiser mon (ou mes) repositories ?
En effet, je ne souhaiterais pas forcément diffuser toutes mes versions de travail : il m'arriçve parfois de coder sans savoir exactement ou je vais : je sais ce que je veux, mais n'ai pas forcément une vision précise de comment faire (surtout lorsque je ne connais pas bien le langage utilisé par exemple). Donc il m'arrive parfois de partir dans une direction, pour me rendre compte que ce n'est pas la bonne et revenir en arrière, ou écrire du code crade et moche, à coup de copier/coller par exemple, que je retravaille ensuite et refactorise pour avoir quelque chose de plus propre.
De ce fait, par pudeur et par respect pour les autres, je ne souhaite pas forcément mettre à disposition ces versions intermédiaires moche et crade, mais plutot garder ça pour moi (avec commits intermédiaires dans mon repo local), et ne diffuser que les verions qui me paraissent suffisamment propre et finalisées.
Est-ce possible de faire ça, sans que ceci ne perturbe trop les autres contributeurs ?
Merci d'avance pour votre retour d'experience.
2/ je souhaiterais également pouvoir diffuser plusieurs versions de mon code :
- une version dite stable qui elle ne bougerait que très peu souvent
- une version de développement/test/rc qui elle serait diffusée à fin de test pour détecter les bugs.
- une version de travail qui serait quant à elle accessible en lecture par qui le veut, mais en écriture uniquement par une 'core developpement team" : celle-ci serait mise à jour régulièrement par les contributeurs "officiels". Si j'en reviens au point précédent, ce serait ce repository par exemple dans lequel je diffuserai les versions suffisamment propres et finalisées de mon code, à partir de ma (ou mes) copie(s) locale(s).
Que pensez-vous de cette organisation ? Avez-vous des améliorations à proposer ? Faudrait-il plusieus dépots Git/Mercurial (ou autre) ? Comment faites-vous sur vos projets ?
Remarque : peut-être que je ne diffuserai jamais mon code, mais la curiosité me pousse à vous poser ces questions.
# utilisation de l'aspect décentralisé de git/hg
Posté par yohann (site web personnel) . Évalué à 1.
Salut,
Je ne sais pas si mon commentaire peut t'intéresser car je suis dans le même cas que toi, tu coup j'ai peu d'expérience en matière de distribution de code, mais je profite de l'aspect décentraliser de git:
J'utilise un dépot git sur mon serveur, et j'ai une copie du repo sur github, j'ai une autre copie local, je push systématiquement sur mon serveur, et je push sur github seulement les versions "propres".
ensuite c'est sans doute un faux problème car rien n'empèche avec les DVCS de ne pusher que du code propre quitte à utiliser la commande rebase pour même avoir des commit propres. Cela dit je ne pense pas que ce soit génant sur des petit dépots unipersonnel que le code ne soit pas super propre, et encore moins l'historique des commits (bon évidement les commits sur le kernel c'est autre chose, mais j'en suis pas là).
# Publication et propreté
Posté par benoar . Évalué à 5.
D'un côté, ça se comprend, mais d'un autre, tu verras que le travail de refactorisation ça n'est pas anodin, et ça prend parfois beaucoup de temps. Au point où parfois tu ne finis par pas diffuser le code parce que tu n'as pas le temps de le refactoriser… (histoire vécue) Perso, j'ai appris à essayer de mettre vaguement au propre au moment où je code (éventuellement en squashant quelques commit, ou en essayant de pas commiter trop vite ; il y a un bon « rythme » à trouver entre tous commiter dès que possible, chose très facile en git, et prendre un peu son temps pour ne pas avoir trop de minuscules commits), et à ne pas faire trop attention aux « détails » de propreté une fois que c'est fait : c'est super chiant de revenir sur son code des jours ou des semaines après, parfois. Il faut accepter de publier du code pas tout à fait propre, parce que sinon ça devient une sorte de psychose qui t'empêche de publier plutôt qu'autre chose.
Avant du publier, oui, rebase autant que tu veux. Mais une fois publié, c'est public, c'est fini. En plus, publier des choses pas forcément idéales que tu corriges après, ça permet de montrer aux gens comment tu fais des erreurs mais aussi comment tu les corriges : c'est plus « humain », et ça apprend aussi à ceux qui te lisent.
Ne te prends pas trop la tête sur une organisation tip-top dès le départ : avec l'expérience, tu auras sûrement envie de changer… Donc je te conseille de faire un seul répo, avec tes branches qui correspondent aux stades de développement dont tu parles (en gérant bien évidemment comme tu le souhaites les permissions).
Je pense que tu te prends beaucoup trop la tête sur la « propreté » d'un code :-) Tu n'en mourras pas, de publier des trucs « pas propres ». Au contraire, je pense que ça t'apprendra d'autant plus, car c'est en essayant et en se plantant qu'on apprend à s'améliorer.
[^] # Re: Publication et propreté
Posté par freem . Évalué à 5.
Accessoirement, un code qui nous paraît propre à un moment donné nous semble parfois à vomir 6 mois plus tard :)
[^] # Re: Publication et propreté
Posté par totof2000 . Évalué à 4.
Imagine l'effet que te ferait du code crade 6 mois après … ;)
[^] # Re: Publication et propreté
Posté par freem . Évalué à 3.
Pas besoin d'imaginer, je connaît :D
[^] # Re: Publication et propreté
Posté par totof2000 . Évalué à 2.
Disons que je n e cherche pas la perfection du premier coup, mais je cherche quand même un truc suffisamment bien pensée pour ne pas à avoir à revenir dessus.
Globalement, je ne pense pas : si je ne publie pas, c'est avant tout pour deux raisons :
# les branches.
Posté par freem . Évalué à 3.
À l'époque de SVN, les développeurs faisaient ce travail à la main, avec 3 sous dossiers principaux ( dans les projets que j'ai pu voir en fouillant sans contribuer ):
Chacun de ces dossiers contenait un copier/coller des sources.
Cette façon de travailler à été automatisée—et nettoyée—par git ( et par mercurial j'imagine? ): maintenant, trunk est une branche comme les autres, et l'on tague les commit.
La problématique que tu décris permets d'utiliser ça assez facilement, et d'ailleurs pas mal de projets libres utilisent cette méthodo:
Puis les tags sont apposés sur des commits précis d'une branche pour définir l'état de la branche au moment de ce commit: numéro de version, release candidate, etc.
# Très proprement, avec le flow!
Posté par Jiehong (site web personnel) . Évalué à 4.
Bonjour,
Il y a quelques temps déjà, un gars a écrit un article proposant un modèle d'utilisation avec des dépôts git/hg.
C'est de plus en plus adopté, et pratique. Je te le conseille vraiment.
Il existe des outils pour te faciliter la tâche avec des extensions pour git et pour Mercurial.
[^] # Re: Très proprement, avec le flow!
Posté par totof2000 . Évalué à 3.
Intéressant … je vais regarder ça attentivement. Mais maintenant que tu en parles, il me semble qu'il y a quelques années, un article sur le sujet est sorti dans GLMF. Quelqu'un s'en rappelle-t-il ? Il faudrait que je cherche s'il est en ligne …
[^] # Re: Très proprement, avec le flow!
Posté par phoenix (site web personnel) . Évalué à 3.
J'avais lu l'article que j'avais trouvé très intéressant, et m'en suis inspiré pour le workflow de mes propre projet sous Mercurial.
Par contre je n'ai jamais trouvé l'utilité de l'extension, en faite j'ai même l'impression que l'extension flow complexifie encore plus la compréhension du fonctionnement du gestionnaire de version. Est-ce que vous utilisez l'extension ? Que vous apporte-t-elle de plus ?
De plus j'ai l'impression que le plugin mercurial ajoute une notion de branch de développement se trouvant entre la branche feature et la branch develop. Branch fusionné automatiquement sur develop lors du rabattement d'une branche de feature.
[^] # Re: Très proprement, avec le flow!
Posté par max22 . Évalué à 1.
il y a celui là : Git pour les futurs barbus
il me semble qu'il y en a eu un autre mais je ne suis plus très sûr.
# Tentative d'aide
Posté par El Titi . Évalué à 4. Dernière modification le 24 juin 2014 à 10:23.
Pour le 1/
Quelques principes qui pourraient t'aider à mieux préparer ton code. (En partant du principe que tu ne disposes que d'un repo local)
Déjà réserver ta branche master pour ne recueillir que des commits signifiants et stables.
Je m'explique: Cette branche ne devrait idéalement accueillir que des commits associés bijectivement à une unité changement (feature, bug, refactoring) complètement réalisée. Ceci te permettra éventuellement de reporter un changement complet de manière atomique sur une autre branche et permet de conserver un historique clair.
Comment obtenir cet historique propre alors que tu vas tester de nouvelles idées, t'y reprendre à plusieurs fois avant d'arriver au résultat attendu ?
En repartant de la branche master et en te créant une branche par changement que tu as identifié (feature branch https://www.atlassian.com/fr/git/workflows#!workflow-feature-branch ).
Tu nommes ta branche significativement "nouvel-algo-de-recherche, …) avec un git checkout -b.
Un fois ton changement complété, il te faut l'intégrer.
Tu as as ta disposition tout un arsenal de commandes (squash, cherry-pick, amend, …) mais le plus abouti est le rebase interactif qui te permet de réunir tous les commits, réécrire le commentaire, passer des modifications…
A la fin tu de devrais obtenir plus qu'un commit sur ton master. Tu peux ré-éditer le commentaire pour lui faire porter le nom de ton changement et le corriger si il est inconsistant avec un amend.
Une fois tout bien vérifie, il ne te reste plus qu'à supprimer ta branche de feature locale.
https://www.atlassian.com/fr/git/tutorial/rewriting-git-history#!rebase-i
Pour le 2/ avec une publication
Le mieux est peut-être aussi de commencer à prendre l'habitude de travailler avec un gestionnaire de tickets (par exemple avec Github) qui te permet de mieux échanger avec la communauté et te laisse gérer l'intégration.
Le principe est le même que décrit précédemment mais cette fois-ci les tickets sont explicitement associé aux commit se qui rend l'historique de ton projet encore plus lisible.
La version stable n'accueille que des bugfix et porte les tags des release.
Ta branche de rc est la branche instable qui serait mergée régulièrement mais l'approche décrite précédemment continue d'être valable(une branche par feature et on l'intègre dans la rc dès qu'elle est prête).
Pour ne pas devoir gérer les contributeurs occasionnels (même si tu peux et faire des revues de code avant d'intégrer la branche) es forges mettent à disposition les pulls request (même si ceci existe de bas Git)
Exemple: https://help.github.com/articles/using-pull-requests
Si tu souhaites déjà rentre dans le moule avec les pull request et le gestionnaire de tickets sanns publier ton code,
il me semble que bitbucket te permet de créer des dépôts privés sinon je te conseillerais en auto-hébergement gitblit plus simple à installer que Gitlab et sans limitation.
http://linuxfr.org/news/sortie-de-gitblit-1-4-x
Voilà, j'espère que ça t'aidera
```
[^] # Re: Tentative d'aide
Posté par freem . Évalué à 2.
Je confirme. 5 pour un nouvel utilisateur qui ne paye pas, avec une taille d'équipe maxi limitée à 5 personnes.
On peut "parrainer" des gens ( faire de la pub en fait ) histoire d'augmenter le nombre de dépôt jusqu'a 5 ( +1 par personne amenée ).
Outre ça, je trouve bitbucket bien plus agréable que le lent et bordélique github ( bien que j'y aie un compte également pour contribuer aux projets des autres, de temps en temps ).
Sinon, +1 pour l'explication, bien que ça rejoigne le lien posté par Jiehong, mais au moins c'est en français ( pour certains, ça compte )
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.