Conception de menus diététiques

[jsboige]

Je vous propose de compiler ici les discussions concernant la réalisation de votre projet.

[jsboige]

Comme convenu par email, quelques mots sur git et github :

Git est le protocole de développement collaboratif qui a fini par s’imposer dans le monde entier. Il est fondamental que vous l’appreniez si vous comptez participer un jour à un projet de développement. Il y a 10 ans encore, il existait plusieurs systèmes en concurrence, MSTF, CSV, SVN etc.
La plupart d’entre eux consistaient à mettre en place un serveur centralisant les arborescence de fichiers des différents projets.
Les contributeurs en récupéraient une copie localement et remontaient leur code par le biais de validations successives qui mettaient à jour la version du serveur. C’est sans doute l’image que vous avez en tête si vous découvrez le concept de développement collaboratif. Tous ces systèmes ont été relégués aujourd’hui au profit de Git.

Celui-ci propose un niveau supplémentaire de journalisation qui demande un effort de compréhension, mais dont vous verrez à l’usage que c’est le plus robuste.
Il y est également question de serveur centralisant le code, ce qu’on appelle un dépôt/repository, défini sous forme d’une arborescence de fichiers et de validations entérinant les modification successives apportées à ce code et que l’on vient « cloner » dans un environnement de travail local. La différence est que l’histoire de ces validations n’est pas uniquement stockée sur le serveur comme c’était le cas avant, mais également sur chacune des machines de travail ou le code a été récupéré/cloné. Cette histoire est constituée de « branches » de validations appliquées en séquences, chaque validation comprenant la liste des fichiers ajoutés, supprimés, et modifiés, l’auteur unique de ces changements, ainsi qu’un petit commentaire indiquant ce qui a été fait.

Après chaque contribution élémentaire/atomique apportée à un projet, chaque contributeur est invité à créer une validation (commit en anglais) correspondante, qui vient se rajouter à sa branche de travail, et ce sur uniquement sur sa machine locale dans un premier temps contrairement à ce qui se passait avant. Quand l’auteur souhaite partager son travail avec les membres de son équipe (ce devrait être le cas vous concernant si vous travaillez sur plusieurs machines), il effectue ce qu’on appelle un « push » de sa branche active. Le serveur réceptionne alors sur le dépôt les nouvelles modifications de branche en s’assurant qu’il n’y a pas de conflit (e.g. la modification simultanée par plusieurs auteurs des mêmes lignes d’un même fichier). Vous concernant, les validations du push apparaissent alors dans votre fork sur github.

Les autres contributeurs peuvent alors mettre à jour leurs propres branche en effectuant ce qu’on appelle un « pull/tirage » depuis le serveur sur leur machine. En cas de conflit, le push est interdit et le contributeur est invité à effectuer en amont un pull localement et résoudre le conflit dans sa branche ou une branche temporaire avant de fusionner les branches/le travail et de retenter son push.

La création du fork d’un dépôt permet de faire collaborer plusieurs équipes de développement, chacune sur son propre dépôt. Elle crée une copie d’une ou plusieurs branches du dépôt d’origine sur laquelle une nouvelle équipe est libre faire évoluer ces branches ses propres modifications (validations, push pull etc.) De temps à autre, la nouvelle équipe veut proposer de remonter son travail et fusionner l’une de ses branches sur l’une des branches du dépôt d’origine. Elle n’a pas les autorisations pour le faire directement alors elle fait ce qu’on appelle une « pull-request ». Il s’agit d’une demande envoyée à l’équipe du dépôt d’origine de venir chercher et fusionner les validations de la nouvelle branche. Cette demande crée un fil de discussion sur le dépôt d’origine qui permet aux deux équipes de discuter et collaborer conjointement de façon temporaire sur la branche à fusionner. Une fois la fusion acceptée, chaque branche reprend son indépendance.

La création de pull-requests est devenue aujourd’hui la façon universelle de proposer sa contribution à un projet open-source. Si vous ne souhaitez qu’utiliser un logiciel libre, vous vous contentez de faire un clone du dépôt ou de télécharger le zip de la branche principale. Vous ne serez pas habilités à remonter vos modifications. Si vous souhaitez le faire, vous créez un fork, faites un push de votre modifications sur votre fork et créez une pull request. Je suis convaincu que ça deviendra rapidement pour nombre d'entre vous une deuxième nature comme pour la majorité des développeurs.

Pour finir, j’imagine que vous connaissez github qui est le serveur git le plus connu et centralise la très grande majorité des dépôts de projets open-source. Outre le support du protocole git, il propose pour chaque dépôt une myriade de fonctionnalités comme la notion d’ « issue »/tâche, qui permet de discuter des évolutions/bugs en amont de leur résolution. On associe souvent une pull-request à l’issue qu’elle vient résoudre, et donc j’ai créé cette issue pour votre travail qui devrait nous permettre d’abandonner la communication par email en journalisant ici-même l’ensemble de nos discussions.

Je vous propose donc de me répondre ici par la suite, ou encore dans la pull-request (PR) que vous me ferez dès que vous avez compris comment ça marche. Celle-ci n’a pas besoin d’être définitive, il ne s’agit que de la comparaison de 2 branches sur chacun des dépôts qui peut continuer à évoluer avec ses branches tant qu’elle n’est pas fusionnée. Pour créer une pull request, rendez-vous sur la page de votre fork. Elle doit indiquer le nombres de validations en avance et en retard de la branche principale sous forme de 2 liens. En cliquant sur l’un des liens, github effectue la comparaison dans un sens ou dans l’autre et propose de créer la pull request correspondante.