MountyZilla sur GitHub

J'ai installé Git sur ma machine, vu le b-a-ba de son fonctionnement, et créé un repo local avec diverses versions de MZ. Sous réserve que Tilk, l'auteur original du projet, donne son accord, je souhaite le déposer sur GitHub. De ce que j'ai compris, il sufffit de s'inscrire sur leur site puis... quoi ?

D'autre part pour le moment je ne maîtrise pas la construction d'un module interne d'add-on Firefox, donc je n'ai déposé que les scripts distants. Est-ce qu'il vaut mieux attendre d'avoir le tout, ou créer deux projets différents (module FF + scripts distants), combien de branches vaut-il mieux utiliser... toussa.

Les manip techniques dans l'environnement git ne me posent pas de problème (c'est assez intuitif, et leur doc est assez complète), c'est plus la connaissance des us et coutumes qui me fait défaut.

Ça, c'est une très très bonne nouvelle   

Je vais essayer d'apporter un peu de mon expérience sur le sujet.

En fait, en git, il y a quelques bonnes pratiques et beaucoup de réflexions sur la mise en place d'un workflow.

Je vais commencer par faire un tout petit tour d'horizon sur git.

Quelques termes :
* repo = repository
* PR = pull request (doc)
* DAG = Directed Acyclic Graphs (doc)

Contrairement à SVN qui est juste un VCS (Version Control System), git est un DVCS (Decentralized Version Control System). C'est très important cette notion de décentralisé.
C'est justement pour cela que git ne force pas un workflow et laisse le choix aux développeurs.
Des gens très bien (Atlassian, AF83) proposent des workflow très adaptés au collaboratif. Et d'autre part, le travail sous Github rend la tâche également plus simple.

Voici les idées du workflow que j'applique sur des projets pro et perso :
1. Un repo maitre "upstream" ; c'est celui qui tagge et release les nouvelles versions du projet
2. Chaque contributeur fork le repo maitre et travail sur son repo
3. La contribution se fait par des PR uniquement ; personne ne push directement sur l'upstream
4. Le repo maitre est géré par quelques code-reviewers qui critiquent le code soumis et ont le pouvoir de merger les PR
5. La logique de merging est le no-fast-forward ; ça tombe bien, c'est ce que fait Github quand on merge une PR

Notions sur les branches et les commits :
Sur les repos locaux, c'est comme on le souhaite. On peut avoir une centaine de branches si on le souhaite, cela dépend de l'organisation du développeur. C'est ça l'avantage d'un DVCS. Toutefois, quelques règles lors de la soumission d'une feature :
1. La branche de feature doit être nommée correctement ; le pattern peut être "{type}/{ma-feature}" ; type = devel, fix, hot-fix
2. Par pitié pour les code-reviewers, la branche de feature doit être simple et ne doit pas comporter des milliers de modifications
3. La branche soumise à une PR doit être rebasé ; c'est-à-dire "cleané" de tous commits intermédiaires créés lors de la réflexion du développeur
4. Un commit est unitaire et explicite ; pas de gros commits qui rassemblent pleins de modifications de code et pas de messages de commit "plop", "pouet", "wip", "fix some stuff"
5. Aucun commit n'est fait directement sur la branche "master" ; cette branche doit être stable et releasable à tout moment

Cela donne un DAG linéaire qui n'est qu'une succession de merging de branche de features.

Quelques outils sympa quand on démarre sous git :
* SourceTree (MacOSX)
* Gitk
* Tig

Concrètement, ce que je propose pour MZ dans le but de bien démarrer :
1. Création du compte github de l'organisation "Mountyzilla"
2. Création du repo maitre distant : "mountyzilla" qui contiendra les sources du projet
3. Ajout d'un README à la racine du projet qui comportera les éléments de base pour contribuer : à quoi sert le projet ? comment installer l'env de dev ? comment tester ? comment mettre à jour ? comment contribuer ? sous quelle licence ?
4. Création des issues pour : les bugs, les améliorations, les évolutions

N'hésitez pas à poser des questions et à intervenir si je raconte n'importe quoi   
Si besoin on peut se faire une session irc, gtalk, ...

Dabihul a écrit:De ce que j'ai compris, il sufffit de s'inscrire sur leur site puis... quoi ?

En fait, ce que je te recommande, c'est de :
* créer un compte d'organisation pour Mountyzilla
* te créer un compte personnel

Dans un premier temps, il faut initialiser le repo "mountyzilla" sur le compte de l'organisation. Une fois cela fait, tu peux te positionner sur ton repo local et faire un faire un `git add . && git commit` (exemple de message de commit : "Mise en place du code source existant").
Tu peux ensuite ajouter un "remote" nommé "upstream" qui pointe sur "git@github.com:Mountyzilla/mountyzilla.git" en utilisant la commande : `git remote add upstream git@github.com:Mountyzilla/mountyzilla.git`. Tu pourras ensuite effectuer un `git push upstream master` pour initialiser le repo distant.
Ensuite, depuis ton compte Github, tu peux aller sur la page du projet Mountyzilla/mountyzilla et forker le projet. Cela va te créer sur ton compte Github un nouveau repo "mountyzilla".
Enfin, sur ta machine local, tu pourras cloner ce repo créé via un `git clone git@github.com:Dabihul/mountyzilla.git`. Cela te permettra par la suite de travailler sur ton repo local, de pusher sur ton repo distant (github) et de soumettre des PR via github sur le repo de l'organisation.
Via le compte de l'organisation, tu pourras tagger des releases et soumettre les nouvelles versions du module FF.

Dabihul a écrit:D'autre part pour le moment je ne maîtrise pas la construction d'un module interne d'add-on Firefox, donc je n'ai déposé que les scripts distants. Est-ce qu'il vaut mieux attendre d'avoir le tout, ou créer deux projets différents (module FF + scripts distants), combien de branches vaut-il mieux utiliser... toussa.

J'ai déjà créé des extensions pour chrome mais pas encore pour FF. Je ne sais pas te répondre pour l'instant. Je vais me renseigner sur le sujet   

Rokü a écrit:3. La branche soumise à une PR doit être rebasé ; c'est-à-dire "cleané" de tous commits intermédiaires créés lors de la réflexion du développeur

Alors ça je pige pas bien. Je croyais que lors d'un push, tout l'historique des commits était repris ? En fait un push = un unique commit distant ? ou bien y'a un moyen de simplifier l'historique au passage qui m'a échappé ?

Rokü a écrit:4. Un commit est unitaire et explicite ; pas de gros commits qui rassemblent pleins de modifications de code et pas de messages de commit "plop", "pouet", "wip", "fix some stuff"

Alors ça ça va me gonfler : réfléchir à un ordre de dépôt pour que la lecture soit simple... ça va à l'encontre de ma nature profondément bordélique  Et du coup je crois que j'attendrai d'avoir fait l'intégration de la gestion de Mélange pour faire mon 1er commit, sinon comme il touche à beaucoup de scripts ça va faire des commits assez violents.

Bon sinon j'ai bien pigé l'orga du compte master / compte dev, même si vu l'envergure du projet je vois pas trop l'intérêt de devenir schyzo... mais bon. Je vais quand même finir de lire la doc que tu as indiquée pour me faire une meilleure idée.

Je note aussi qu'il faut que je fasse un petit tuto à coller dans un ReadMe à l'intention des devs. En local ce que j'ai fait c'est monter un apache local qui simule MH (et qui me sert aussi de dépôt pour mes scripts) pour faire les tests avant déploiement.

Je viens de finir la doc de Atlassian (très bien écrite d'ailleurs). En fait avant même de savoir que Git existait, je travaillais essentiellement en mode Gitflow avec :
- une branche "online" = master, celle postée sur le serveur MZ
- de très rares hotfix réalisés et testés directement sur la version online/master locale avant d'être déployés
- une branche "perso.backup" = devel de développement générale, qui me servait à stocker un état du dev quand je faisais de grosses modifs
- une branche "perso" de dev libre, qui correspond essentiellement aux branches de "feature", sauf que j'en ai qu'une où je fais un peu tout à la fois  

En fait je vois pas bien comment on peut fonctionner différemment, je plains les devs qui bossent en mode SVN (et surtout ceux qui doivent se taper les reviews en cas de pépin - "y'a eu un problème entre la release 304 et la release 427, démerdez-vous pour réparer." "wtf?"). La seule nouveauté pour moi sera donc de m'organiser pour travailler par feature et non en mode foutoir complet, ce qui n'est sans doute pas plus mal 

Yes, tu l'as très bien di Dab'. Sous SVN, c'était une atrocité sans nom. Tu étais obligé de remonter jusqu'au commit problématique et tout reverter. Généralement, ça ne se passait jamais comme ça. Personne ne recherchait dans l'historique et ça finissait par un gros hotfix dégueulasse sur la branche principale sans comprendre pourquoi...

Pour l'histoire du compte pour l'association et d'un compte pour toi. Dans un premier temps et pour te faciliter la tâche, tu peux très bien déclarer être le repo distant maitre. Ça ne me pose pas de problème

Pour te répondre par rapport au rebase.
Tu as bien compris le principe des commits et des push.
En local, tu commits x fois. Du coup, ton repo local est "en avance" par rapport au repo distant. Tant que tu n'as pas pushe, tout tes commits locaux sont reorganisables, supprimables, renommables... C'est le principe du rebase. En git, vulgairement, on ne parle pas d'historique, car chaque commit est juste un pointeur vers les modifications et le prochain commit. Par contre, du moment où tu as pushe tes commits sur le repo distant, c'est non-rebasable car entre temps un autre dev a peut-être pullé les commits et ça foutrait en l'air son repo si tu changes les pointeurs.

En tout cas, c'est cool. J'ai hâte de pouvoir contribuer. J'en suis sûr qu'en lisant du code je vais apprendre plein de trucs sur le fonctionnement du jeu

Coucou Dab', tu t'en sors ?
Je peux t'aider ?  

Pour l'instant j'apprends à utiliser "rebase" pour éviter de faire des commits moisis sur le futur serveur.
Et j'apprends également à mes dépends que travailler par branche de feature quand on à l'habitude de tout faire à la fois n'est pas aussi simple que je l'aurais cru... par exemple j'ai essayé d'extraire toutes les modifs faites sur un unique fichier parmi l'ensemble de tous les commits que j'ai fait eh bin... c'est la me-merde.

Deux astuces qui peuvent te faciliter la vie :
- l'option -p de la commande git add
- la commande git cherry-pick

Le travail en branche et commit unitaire est un réflexe à prendre qui n'est pas évident au début, clairement. Courage

Question : y'a moyen de casser un commit en 2 ?
A-B-C-... --> A-A'-B-C-...

J'imagine en faisant un truc du style : je récup les fichiers dans l'état B, je place la HEAD sur A, je crée le commit A' sur une nouvelle branche, et je rebase le reste de la vieille branche sur A' ? (Et comment je vire l'ancienne branche de l'historique ? -d ça vire juste la branche, sans toucher à l'arborescence.)

La découverte qui m'a facilité la vie pour l'instant c'est surtout l'option -i (interactive) de rebase... ça fait tellement trop bien le café que j'ai failli pleurer 

En fait le rebase c'est un remake de l'Apprenti Sorcier : il laisse des branches inutiles partout, et impossible de les supprimer. (Git a l'air totalement incapable de supprimer définitivement un commit, sauf si c'est le tout dernier. Wtf??) Nan en fait j'avais copié-collé un fichier d'options de Git qui le rendait complètement parano, avec la config de base tout va bien.

Bon bin je crois que j'ai tout ce qu'il me faut :

Code:

git rebase -i ___
git merge --no-ff --no-commit ___

répondent à tous mes besoins ! Y'a moyen de *copier* quand on fait un rebase, plutôt que de *déplacer* la branche ?

Aaah le git rebase -i. Je l'aime tellement.
Qu'est-ce que tu entends par copier plutôt que déplacer ? Le principe de rebase est juste de déplacer le pointeur de départ de ta branche. Du coup je ne comprends pas ton besoin.

Si je veux faire ceci par exemple :

Code:

A-B          A-B-C'-D'
 \     --->   \
  C-D          C-D

en conservant ma branche de dev intacte. J'ai essayé en collant 2 branches en D et en ne demandant un rebase que d'une branche, mais il déplace les deux.
Mais bon je me suis démerdé à coup de rebase --onto.

Aaah, je crois comprend l'utilité. Tu souhaites avoir une branche de feature, travailler sur des sous-branches et merger tes sous-branches en conservant ton pointeur sur le commit de départ de ta branche.

Code:


              C---G stopic1
              |
              H---I stopic2
              /
        A---B---C' topic
      /
D---E---F master


C'est bien ça ?

C'est ça oui. L'idée c'est un peu de merger ma sous-branche sans la merger vraiment.

En fait il y a au moins un fichier dans MZ qui va être sans arrêt modifié : le fichier libs (librairie de fonctions). Ce que je veux faire, une fois que j'ai ouvert plusieurs branches de feature (=stopic) sur ma branche dev (=topic), c'est pouvoir transmettre aux autres au moins les modifs faites dans libs.
Donc je rebase --onto un ou deux commits de ma branche de feature1, je teste un temps la branche dev et si tout va bien je rebase les autres branches de feature dessus.

Code:

            E---H feature1                      E---H feature1                      E' feature1
           /                                   /                                   /
          | F---G feature2                    | F---G feature2                    | F'--G' feature2
          |/                  --->            |/                  --->            |/
      C---D dev                           C---D---H' dev                  C---D---H' dev
     /                                   /                               /
A---B online                        A---B online                    A---B online

OK! J'ai compris. Mais du coup tu n'as pas besoin de faire un rebase --onto. As partir de dev, tu fais du cherry-picking et ensuite sur tes branches de features sur as juste à faire des git rebase dev. Non ? Ou alors j'ai zappé une étape.

Pour moi le --onto sert uniquement à "deplugger" une branche vers une autre.
Du genre,

Code:


                                         H---I---J topicB
                                        /
                             E---F---G  topicA
                            /
               A---B---C---D  master

git rebase --onto master topicA topicB, va donner :
                            H'--I'--J'  topicB
                           /
                           | E---F---G  topicA
                           |/
               A---B---C---D  master


Aller, encore deux petites questions pour l'expert :

1) Pour forcer une vérification lors d'un merge, j'ai créé un driver perso qui retourne une erreur quoi qu'il arrive (et du coup me laisse le temps de lancer meld et de checker les modifs avant de valider le merge).
Y'a moyen de forcer une vérif lors d'un cherry-pick ?

2) 7. One person or legal entity may not maintain more than one free account.

Rokü a écrit:En fait, ce que je te recommande, c'est de :
* créer un compte d'organisation pour Mountyzilla
* te créer un compte personnel

Euh... du coup j'ai droit de créer plusieurs comptes ou pô ?

Dabihul a écrit:Aller, encore deux petites questions pour l'expert :

Oula, je ne suis pas expert. Je l'utilise beaucoup, mais je pense avoir encore beaucoup à apprendre sur les possibilités qu'offrent git

Dabihul a écrit:
1) Pour forcer une vérification lors d'un merge, j'ai créé un driver perso qui retourne une erreur quoi qu'il arrive (et du coup me laisse le temps de lancer meld et de checker les modifs avant de valider le merge).
Y'a moyen de forcer une vérif lors d'un cherry-pick ?

Tu parles des hooks ? Si c'est le cas, non je ne connais pas de moyen de faire cela sur un cherry-pick.
Tu as une liste assez exhaustive de ce que tu peux faire avec les hooks juste ici : http://githooks.com/

Dabihul a écrit:
2) 7. One person or legal entity may not maintain more than one free account.

Rokü a écrit:En fait, ce que je te recommande, c'est de :
* créer un compte d'organisation pour Mountyzilla
* te créer un compte personnel

Euh... du coup j'ai droit de créer plusieurs comptes ou pô ?

En fait, je t'ai di une bêtise, désolé  
Tu pourras créer une organisation avec ton compte une fois connecté sur Github.
Dans la partie, Account Settings > Organizations > Create new organization.
Tu pourras alors poser les sources sur le compte de l'orga.

Bon, bon, bon... Maintenant que je maitrise à peu près l'outil, j'ai essayé de mettre quelques fichiers en ligne. Mais j'ai du foirer une étape, parce que quand je tente de cloner ce que j'ai mis en ligne, j'obtiens... un gros que d'al. Je récupère bien les fichiers déposés, mais la structure de repo est absente
En plus il considère que la première branche que j'ai déposée est la branche par défaut, alors que c'est "online" qui devrait l'être :'( Pfff, malgré toute la doc que j'ai compulsée, on dirait que j'ai encore beaucoup à faire.

EDIT : ah oui, et quel encodage / fin de ligne faut-il utiliser sur GitHub ? J'ai tout converti en ISO-8859-15 CRLF (en window$ quoi), mais apparemment c'est pas ça...

Bon, mis à part les soucis d'interprétation du markdown lié à l'encodage des fichiers, j'ai à peu près tout résolu. Par contre github est bloqué depuis mon boulot (wtf?) :

Code:

error: Failed connect to github.com:443; Connection timed out

Je serai donc dorénavant forcé de bosser au lieu de coder, un comble.

Je dépose la branche dev ce soir, et tu pourras jeter un oeil si tu veux. Il faudra aussi que je splite le Readme que j'ai mis en ligne, que j'ajoute la doc... dommage que les vacances soient finies, il va y avoir pas mal à faire !

Dabihul a écrit:Bon, bon, bon... Maintenant que je maitrise à peu près l'outil, j'ai essayé de mettre quelques fichiers en ligne. Mais j'ai du foirer une étape, parce que quand je tente de cloner ce que j'ai mis en ligne, j'obtiens... un gros que d'al. Je récupère bien les fichiers déposés, mais la structure de repo est absente

Pas compris   

Dabihul a écrit:
En plus il considère que la première branche que j'ai déposée est la branche par défaut, alors que c'est "online" qui devrait l'être :'( Pfff, malgré toute la doc que j'ai compulsée, on dirait que j'ai encore beaucoup à faire.

Tu peux modifier la branche par défaut dans la configuration du repo.

Dabihul a écrit:
EDIT : ah oui, et quel encodage / fin de ligne faut-il utiliser sur GitHub ? J'ai tout converti en ISO-8859-15 CRLF (en window$ quoi), mais apparemment c'est pas ça...

Recommandation : UTF-8, CRLF.
Explication pour la fin de ligne : http://stackoverflow.com/questions/5813311/no-newline-at-end-of-file