Une place pour une véritable innovation. Partagez vos propres utilitaires créés avec la communauté Manjaro.
Questions et discussions sur la programmation et le codage.
Répondre

[git] Participer au développement de Manjaro

#1Messageil y a 1 an

La participation des français au développement de Manjaro ce compte très facilement avec les doigts d’une seule main !

Pour y remédier, je vous propose un petit tuto sur git (en quelques posts) et non manjaro-iso-tools (existe déjà).

Le développement de Manjaro se passe sur Github  dans deux dépôts en particulier :
- manjaro-tools-iso-profiles : nous trouvons la configuration de l’iso d’installation avec en particulier les paquets à installer.
- desktop-settings : les réglages de la distribution dans le répertoire /etc/ et les réglages utilisateurs en fonction du bureau.
Le dossier « shared/ »  regroupe les réglages communs à tous les bureaux.

Ces dépôts sont des dépôts Github classiques uniquement accessibles en écriture à une poignée de développeurs Manjaro. Mais il ne faut pas croire qu’ils n’acceptent pas que nous puissions contribuer au code nous même, bien au contraire ! un bug, une faute d'orthographe à corriger, une nouvelle fonctionnalité : nous pouvons le faire.

Pour cela il faut avoir quelques base Git ; rassurez-vous j’ai pu noter que certains développeurs Manjaro ont une connaissance de Git relativement faible, ce qui ne les empêche nullement d’être très actifs.

--------------------------------------------------------------------

Github

Première chose : avoir un compte Github ; attention l’adresse email donnée sera publique…

Les dépôts Github de Manjaro sont pour nous en lecture seule ! Pas grave ; il suffit de créer notre propre copie sur notre compte. Cette copie sera un « fork ». Puisque le fork est sur notre compte et nous appartient : nous avons cette fois ci les droits en écriture !!!
Il ne nous reste donc plus qu’à modifier notre fork puis à envoyer une requête pour que notre fork soit intégré (presque automatiquement) dans le dépôt Git officiel de Manjaro. Cette demande est un « pull request ». Si elle est acceptée par le mainteneur du dépôt, alors notre contribution sera présente dans le prochain iso d’installation.

Les grandes étapes Github sont donc :
1) Je « fork » le dépôt Manjaro en lecture
2) Je rapatrie mon fork sur ma machine (clone/fetch)
… je modifie/ajoute/supprime le code ou le texte et sauvegarde (commit)
3) J’envoie mes modifications locales dans mon fork (push)
4) Je fais une demande pour intégrer mon travail dans Manjaro ( pull request )

Image

A suivre le détail de chaque étape …
1) Créer un fork ; juste un appui sur un bouton
2) récupérer en local mon fork : git clone url_de_mon_fork
… j’édite le code et le sauve avec un git commit
3) git push
4) un petit texte de commentaire et un simple appui sur un bouton

[git] Participer au développement de Manjaro

#2Messageil y a 1 an

Bonsoir,
Tout d'abord Merci pour le sujet .
Une toute 1ère question / exemple (pas forcément bon...) :
- Dans Dolphin, la traduction n'est pas bien francisée; peut-on y intervenir, ou c'est seulement du ressort des devs de chez KDE ? :merci:

[git] Participer au développement de Manjaro

#3Messageil y a 1 an

oui en effet c'est KDE et non Manjaro. Manjaro ne traduit (éventuellement) que ces propres logiciels et fichiers.

pour kde ça se passe ici et il est possible de suivre en temps réel l'avancée la

A noter que généralement pour les traductions, le service github (ou autre) utilise un plugin qui utilise un service web externe (comme transiflex). Alors toute la mécanique (git) est cachée par le service.

Certains logiciels utilisent utilisent uniquement github pour les traductions ; par exemple pacaur alternative à yaourt qui lui utilise le service web : transiflex

[git] Participer au développement de Manjaro

#4Messageil y a 1 an

Le Fork
Notre première étape.

Ici il ne faut pas comprendre ce mot comme nous le rencontrons (souvent) dans l’univers open source. Nous ne faisons pas un fork parce que nous désirons créer un nouveau projet à partir d’un existant ; au contraire, notre but premier est de retourner nos modifications dans le projet d’origine « upstream ».
Cette opération est obligatoire car nous n’avons pas de droits en écriture sur l‘upstream. Bien sur, si nous créons notre propre projet, cette phase peut être passée.

Une fois sur la page du projet auquel nous désirons apporter notre labeur, il faut simplement cliquer sur le bouton « Fork »  en haut à droite

Image

L’opération prend que quelques secondes. Maintenant nous avons un dépôt accessible en écriture (pour nous uniquement)

Notez que le nombre accolé au bouton indique le nombre de forks existant pour ce projet. Ici dans cette capture d’écran nous voyons que 6 personnes vont sans doute contribuer au projet ; il faut aussi ajouter les personnes qui ont un accès en écriture, en tout c’est 10 personnes(contributeurs). C’est énorme pour un petit projet régional !!! desktop-settings c’est 13 bureaux + les deux officiels et donc il n’y a même pas une personne par bureau !
A titre de comparaison
- Laravel – projet php c’est : 930 contributeurs
- Boostrap – projet css c’est : 670 contributeurs
- Yaourt : 35 contributeurs
- Manjaro-iso-tools : c’est 36 forks mais que 19 contributeurs

Un contributeur est celui qui va aller juste au bout : changer effectivement le code du projet. La liste des contributeurs est dans l’onglet « «Graphs -> Contributors » 

ps : certains contributeurs ont juste changé une seule faute d’orthographe, merci a eux le but est de participer et pas de gagner.

[git] Participer au développement de Manjaro

#5Messageil y a 1 an

Le workFlow
Gérer efficacement son projet Git.

Plusieurs solutions existent, le propriétaire du dépôt upstream peut exiger de suivre une certaine procédure.
Avec manjaro, aucune exigence (ni recommandation ?), nous sommes donc libre de faire du plus simple au plus avancé.

Je vais donc dans un premier temps vous présenter la technique la plus simple. A utiliser uniquement si vous ne faites qu’une petite modification de temps en temps. 30 minutes maximum sans compter le temps de votre travail en local et de vos tests en local pour bien vérifier que votre travail est sans reproche...

Nous venons de créer notre Fork, passons à la suite.

Etape 2,
nous le récupérons sur notre machine ; bonjour la ligne de commande.
Dans un premier temps il faut connaître l’adresse de notre dépôt(Fork) Github, elle est indiqué dans le page principale de notre Fork : https://github.com/<mon_login_github>/<nom_du_fork>.git

En ligne de commande nous faisons une copie locale de notre Fork :

git clone https://github.com/<mon_login_github>/<nom_du_fork>.git
un dossier "<nom_du_fork>" sera créé dans notre répertoire courant avec tous les fichiers du projet et même plus (logs).

Maintenant nous pouvons travailler en local sur le projet.
Nous ouvrons avec notre éditeur favoris le fichier désiré et nous le modifions. Par exemple, nous désirons ajouter un alias au fichier .bashrc :

alias ello= « echo ‘bonjour toi’»

une fois le fichier sauvegardé, il faut impérativement faire une sauvegarde Git. Pour cela nous utilisons la commande git commit en lui passant en paramètre un titre très court explicatif en anglais

git commit -am "add alias"

ps: un commit est une sauvegarde de la différence avec le commit précédent

Notez que l’on fait un commit par fonctionnalité ; correction de 10 fautes d’orthographes c’est un seul commit ! Un bug c’est un commit même si vous modifiez plusieurs fichiers.
Notre travail est fini, maintenant il ne reste plus qu’a le remonter dans le cloud.
Notez que nous remontons uniquement nos commits !


Etape3,
une simple commande va remonter tous nos changements (et uniquement eux - les commits!) dans notre Fork :

git push origin master
Cette commande envoie à Github uniquement nos différences et non tout le projet, c'est donc une commande très rapide même si le projet pèse quelques mégas.
Notre Fork est maintenant différent de la version upstream, nous avons un commit de plus. Notre travail en local est fini.


Etape 4,
Faire un push request

Il ne reste plus qu’a faire profiter la communauté manjaro de nos modifications.
De retour sur notre compte Github, nous allons à notre Fork. Et la magie : Github se rend compte que notre Fork est différent et nous propose un gros bouton « new pull request » 
Image
Il va falloir maintenant prendre sa plus belle plume « anglaise » pour commenter notre requête. Et oui, même si nos modifications nous semblent opportune, c’est au propriétaire du dépôt upstream de décider si oui ou non il accepte notre travail en l’état ; si c’est la résolution d’un bug c’est facile d’argumenter.
- Votre travail doit être beaucoup beaucoup plus intelligent que mon pauvre exemple !!!
- Le pull request ne doit pas être sur de nombreux changements (faire 36 pull request est la bonne méthode)
- Vos modifications ne cassent rien
- Vos modifications prennent bien en compte que Manjaro est international (donc pas d’alias maj) et tourne sous systemd et openrc, et que vous ne cassez rien dans les autres bureaux.
- Si vous avez récupéré le dépôt en local c’est pour le tester, envoyer quelque chose qui ne fonctionne pas c’est vous griller (définitivement) auprès des développeurs Manjaro.
- Et 36 autres critères ...

A ne pas faire :
Image

Une fois envoyée, il faut attendre quelques heures/jours que le propriétaire ou responsable du bureau réagisse. Un pull request sur Github est de la même forme qu’un nouveau sujet dans un forum, vous pourrez donc échanger si il y a lieu.

- Le propriétaire dit ok … votre commit est alors intégré automatiquement dans le projet original (upstream), vous êtes un des contributeurs :fete:
- Le propriétaire peut demander quelques changements et/ou explications : il est encore possible de modifier vos fichiers en local et de refaire un autre commit. Ce nouveau commit sera automatiquement intégré au pull request en cours et le propriétaire recevra une notifiction lors du git push.
- le propriétaire peut refuser ! :pleure: Et fermer le pull request. Ne soyons pas trop dépité, il donne toujours les raisons ; un pull request de perdu c’est 10 de passés :)



------------------------------------------------------------


Cette technique est très simple et rapide, elle peut ne prendre que 15..20 minutes. Mais si vous désirez être un contributeur actif, malheureusement elle a de nombreuses limites :

- une fois le pull request fait, il n’est plus possible de travailler sur votre fork sinon tout changement va être intégré aussi dans le pull request et la il y a tromperie sur votre demande initiale de pull request. Et si votre pull request dure 15 jours, c’est 15 jours de vacances forcées.

- vous avez beaucoup d’idées, de motivation, il va falloir attendre attendre entre chaque pull request, idéal pour perdre sa motivation.

- Les autres contributeurs apportent aussi leur pierre à l’édifice, et donc au bout d’un moment le Fork n’est plus à jour et donc votre travail peut devenir incompatible avec l’upstream(dépôt original). Le détruire sur votre compte Github (après l'étape 4) et en refaire , ca marche mais pourquoi faire et refaire cette tache ... bof



Pour remédier ces problèmes, Il y a la possibilité d’utiliser des techniques Git un peu plus poussées : configurer l’upstream, faire des fetch à la place d'un git clone, utiliser des branches .
A suivre...

[git] Participer au développement de Manjaro

#6Messageil y a 1 an

Etre à jour

Maintenant nous allons nous passer du git clone et de devoir supprimer notre Fork pour être à jour. Nous allons déplacer le flux (2) du shéma précédant.

Il faut indiquer à notre dépôt local que nous avons 2 sources :
- notre Fork valeur par défaut
- l’upstream (manjaro)

Après avoir fait notre premier git clone, nous créons une branche (nous verrons après) se nommant « upstream » qui pointe sur le source originale du projet : l’upstream.

git remote add upstream https://github.com/manjaro/<nom_du_projet>.git

Grâce à cette nouvelle branche, nous pouvons nous passer du git clone et faire nos mises à jours a volonté.


Maintenant nous pouvons récupérer à loisir en local la dernière version officielle avec un fetch :

git fetch upstream


il nous reste a fusionner la branche upstream/master sur notre branche perso/master

git checkout master
git merge upstream/master
je me suis positionné dans ma branche master et j'ai fusionner la branche upstream dans la branche courante.

Très bien, mais mon Fork sur Github n’est pas à jour lui ! Une petite commande push :

git push origin master


Nous avons maintenant les commandes pour avoir un dépôt en local (et Fork) toujours à jour même si 36 commits rentrent par jour.
Cette technique est obligatoire si notre Fork a une durée de vie longue alors que le dépôt Manjaro d’origine continue d’évoluer grâce aux autres contributeurs.

Nous avons maintenant un flux différent du premier :
Image
ce flux est la bonne méthode pour travailler en équipe (plus on est de fous...) et sur le long terme (plus c'est long...)

A suivre ... les branches (pour finir - enfin :rigole: )

[git] Participer au développement de Manjaro

#7Messageil y a 1 an

les Branches

Il nous reste plus qu’un gros problème :
- une fois le pull request fait, il n’est plus possible de travailler sur votre fork sinon tout changement va être intégré aussi dans le pull request et la il y a tromperie sur la demande initiale de pull request. Et si le pull request dure 15 jours, c’est 15 jours de vacances forcées.


C’est ici que le concept de branches vient à notre secours. Les branches sont ressenties comme des dépôts parallèles à notre dépôt principal nommé « MASTER ». Des bifurcations qui seront fusionnées probablement un jour dans la branche master qui représente la version stable de notre dépôt.

Vous en connaissez une, depuis le début nous travaillons avec la branche master, celle par défaut. Nous avons vu upstream qui est une branche contenant le dépôt Manjaro. Cette branche a une particularité, nous n’écrivons jamais dedans, elle est modifiée uniquement lors d’un fetch par le contenu du dépôt Manjaro.

Nous pouvons créer autant de branche que désiré et elles ont généralement pour but d’êtres fusionnées dans la branche master. Nous créons une branche par fonctionnalité ; par exemple :
- version française
- réparation/test d’un bug
- ajout d’une nouvelle fonctionnalité

Il faut retenir que toute la branche servira pour un pull request. Et oui nous ne faisons plus un pull request (de la branche master) mais un pull request (d’une fonctionnalité).
Et puisque nous faisons un pull request d’une branche X, tout travail postérieur dans une autre branche ne rentrera pas dans le pull request. C’est pourquoi nous créons toujours une branche et ne travaillons jamais sur la branche master : nous avons toujours les mains libres pour continuer à travailler, même si le pull request reste ouverts de nombreux jours. Et de plus, si le pull request est refusé, nous détruisons tout simplement notre branche et notre dépôt local reste propre , nous n’avons pas pollué notre dépôt avec du code qui est maintenant obsolète.

Passons aux commandes git :

Pour créer une branche en lien direct avec upstream

git checkout -b MA_BRANCHE_LOCALE upstream/master


Nous somme dans la branche nommé « MA_BRANCHE_LOCALE » nous pouvons maintenant travailler et faire nos commit.

Après travail il nous reste à pousser la branche (et uniquement elle) vers le Fork

git push origin MA_BRANCHE_LOCALE


Pour lister les branches : git branch
Pour basculer dans une branche : git checkout "le_nom_de_la_branche"
A noter qu’un basculement dans une branche va automatiquement mettre à jour les fichiers dans le répertoire avec le contenu de cette branche.
Une fois que le pull request de la branche a été accepté, on la récupère dans master local avec un fech et merge et l’on supprime cette branche en local et sur le Fork. La boucle est bouclée.

Notre travail avec les Branches peu être schématisé comme ceci :
Image

J’ai fait l’impasse sur beaucoup de fonctions Git, ce tuto était pour vous donner la recette (et la compréhension j’espère) pour une bonne utilisation de Github (ou gitlab). Vous devez maintenant être armés pour participer a tout développement collaboratif sur Github.
Une fois que vous avez compris ce schéma final, il ne vous reste plus qu’a connaître les nombreuses commandes Git. Le web pullule de documentation et d’aides mémoires pour maîtriser les commandes Git.

Pour aller plus en profondeur :
- bon article pour en savoir plus sur les branches 
- Et la référence Git, le livre (fr) Pro Git

Répondre