Forum général.général Gestionnaire de version : organisation et distribution

Posté par . Licence CC by-sa
3
20
juin
2014

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 (page perso) . É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 . Évalué à 5.

    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.

    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.

    Est-ce possible de faire ça, sans que ceci ne perturbe trop les autres contributeurs ?

    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.

    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 ?

    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).

    Remarque : peut-être que je ne diffuserai jamais mon code, mais la curiosité me pousse à vous poser ces questions.

    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 . Évalué à 5.

      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.

      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 . Évalué à 4.

        Accessoirement, un code qui nous paraît propre à un moment donné nous semble parfois à vomir 6 mois plus tard :)

        Imagine l'effet que te ferait du code crade 6 mois après … ;)

    • [^] # Re: Publication et propreté

      Posté par . Évalué à 2.

      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).

      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.

      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.

      Globalement, je ne pense pas : si je ne publie pas, c'est avant tout pour deux raisons :

      • je n'ai pas forcément le temps de suivre au jour le jour le code que je développe : je fais ça sur mon temps libre qui varie selon les périodes (j'ai également une épouse et une fille, et je ne veux pas non plus les négliger).
      • je ne suis pas forcément convaincu que mon code intéressera d'autres personnes (peut-être à tort?) au moins dans l'état actuel dudit code qui en est qu'au stade d'expérimentations.
  • # les branches.

    Posté par . É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 ):

    • trunk
    • branch
    • tag

    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:

    • master, ou stable, pour les bug fixes ( une fois la première stable atteinte, naturellement )
    • experimental, ou devel, peu importe le nom, pour la future version stable
    • une branche par fonctionnalité ou tâche à effectuer, que l'on merge dans experimental quand ça semble marcher.

    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 (page perso) . É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 . É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 (page perso) . É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 . É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 . Évalué à 4. Dernière modification le 24/06/14 à 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 . Évalué à 2.

      il me semble que bitbucket te permet de créer des dépôts privés

      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.