Projets composés de plusieurs catégories

L’auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonsoir,

Je souhaite publier le code source de travaux que j’ai effectué durant mes études d’informatique à l’université sur GitHub. Concernant certain projets, je me pose une question. Je vais prendre un exemple : un projet que j’ai eu est composé d’une application créée sous Unity et son site vitrine. Dois-je créer deux projets ou deux dossiers dans le même projet ? Enfin, la création d’une organisation serait-elle plus judicieuse ?

Merci d’avance.

+0 -0

Cette réponse a aidé l’auteur du sujet

J’aurais certainement fait 2 projets. Les deux me semblent indépendants, si quelqu’un veut reprendre l’application, il n’a pas besoin du site vitrine.

À la limite dans l’application un exemple d’intégration dans un index.html. Mais pas tout le site dans le projet de l’application Unity.

Avoir des dépots qui dépendent les uns des autres n’est pas un problème.

Édité par ache

ache.one                 🦹         👾                                🦊

+0 -0
Auteur du sujet

Merci pour cette réponse. Elle me paraît logique. Je vais donner un deuxième exemple, plus complexe. J’ai réalisé en groupe un projet de domotique. Il y avait des capteurs branchées sur une Raspberry Pi via une carte Arduino. Les capteurs sont gérés par des scripts en Python et C. Aux événements choisis, on a une notification qui est envoyé par email, une autre sur une application Android. De plus, il est possible de voir un aperçu de la caméra (un des capteurs) depuis un site web et l’application Android.

Comment gérer tout ça sur GitHub ?

+0 -0

Cette réponse a aidé l’auteur du sujet

Il n’y a pas de bonnes ou de mauvaises situations façons de faire ; c’est avant tout une question de choix en toute connaissance de cause. Certains voudront multiplier les repositories git pour limiter l’adhérence entre les projets. ÀMHA, le gros avantage d’avoir plusieurs repos, c’est de pouvoir avoir des historiques plus clairs et plus spécialisés. Après, Google par exemple est connu pour avoir dans certains cas une démarche inverse avec un énorme repo qui contient des millions de lignes de code.

C’est avant tout à toi de voir ce que tu veux faire. Déjà, qu’est-ce qui est le plus pratique pour toi ? Il peut être tout aussi pertinent d’avoir une chaîne de compilation robuste qui te permet de compiler séparement chaque projet, afin de les garder ensemble parce que les codes sources gardent une forte adhérence entre eux.

Édité par lthms

Merida is so cool · “Now that I have built my very own hammer, nothing looks like a nail anymore. ”

+0 -0

Cette réponse a aidé l’auteur du sujet

[…] Dois-je créer deux projets ou deux dossiers dans le même projet ? Enfin, la création d’une organisation serait-elle plus judicieuse ?

Helmasaur

Si ton site vitrine est un simple site web statique, tu peux aussi jeter un coup d’oeil à GitHub Pages. En gros, l’idée c’est d’avoir une branche complètement séparée de ton projet dans laquelle tu versionnes ton site web. Cela permet de pouvoir afficher la dernière version du site directement en visitant http://username.github.io/nom-du-projet/. La branche séparée permet également de ne pas avoir de site web qui fait tâche dans la branche master.

Personnellement, je ne passerais par une organisation que s’il s’agit d’un projet relativement grand, avec pas mal de développeurs et plusieurs dépôts liés au projet.

[…] Comment gérer tout ça sur GitHub ?

Helmasaur

Si tu héberges tes projets dans des dépôts GitHub publics, l’idée c’est que n’importe quelle personne qui viendrait visiter ton projet soit capable de télécharger les sources et faire fonctionner le projet.

En général, il suffit d’ajouter un fichier README ou INSTALL à la racine du dépôt qui décrit les différentes étapes nécessaire à la mise en place et au fonctionnement du projet (outils nécessaires, dépendances, etc.). Il est même possible d’écrire dans le GitHub Wiki de ton projet. Note que dans les deux cas, si le texte est en markdown, GitHub est capable de l’afficher correctement. (Note aussi que le contenu du README apparaît sur la page d’accueil du projet.)

+2 -0
Auteur du sujet

Le jeu et le site se partage des données qui proviennent de la même base de données. C’est tout de même indépendant. Je dirais qu’il y a deux modules distincts pour ce projet.

Concernant la domotique, je sais encore moins comment gérer cela. En effet, il y a comme module :

  • Raspberry Pi et Arduino
  • Base de données
  • Site Web
  • Application Android

Enfin, je pense que ça n’a pas été compris mais il s’agit de projet qui ont été fait il y a quelques années à l’université. Je veux juste mettre les sources en ligne. Concernant le jeu, il n’est pas impossible que son développement soit complété (ce n’est pas sûr non plus). Dans tous les cas, je préférerai voir ces fichiers disponibles pour tous plutôt qu’ils prennent la poussière sur mon disque dur.

EDIT : je souhaite aussi mettre en ligne le rapport ainsi que le diaporama de présentation.

Édité par Helmasaur

+0 -0

Cette réponse a aidé l’auteur du sujet

Tout dépends de ce que tu souhaites faire.

Si c’est juste stocker/ranger des codes sources en rapport avec un projet universitaire autant tout mettre dans le même répo.

Si c’est pensé à la réutilisabilité et d’un point de vu pratique si tu souhaites continuer le projet ; un répo par projet indépendant et un autre pour la présentation me semble le plus adapté.

ache.one                 🦹         👾                                🦊

+0 -0
Auteur du sujet

Peut-on créer une organisation et y ajouter des dépôts que j’ai déjà créé ? Je me dis qu’autant les séparer au cas où c’est repris (par moi ou quelqu’un d’autre). De plus, comment seront affiché mon organisation sur ma page GitHub ?

+0 -0

Cette réponse a aidé l’auteur du sujet

À toi de voir si ça vaut le coup de séparer tes modules. S’ils sont fortement liés (i.e. si une modification sur un module implique une modification sur un autre), mieux vaut peut-être les laisser ensemble.

Je suis pas sûr que ça vaille le coup de créer une organisation. Si j’ai bien compris, une organisation se comporte plus ou moins comme un compte GitHub, sauf que plusieurs personnes peuvent (plus ou moins) le contrôler. Je ne suis pas sûr de voir en quoi cela est avantageux pour ton cas.

Sur ta page de profil, on verra simplement la liste des organisations dont tu fais partie. Lorsque tu fork ou que tu es sur le dashboard, il faudra donc à chaque fois choisir entre ton compte ou ton organisation (cf. image ci-dessous).

organisations
+0 -0
Auteur du sujet

Je ne savais pas qu’une organisation créait une sorte de compte moral (si je peux me permettre de comparer avec personne physique et morale). Je pense en effet qu’il ne s’agit pas de la bonne solution dans mon cas.

Je pense que je vais créer un seul dépôt et si je veux reprendre, je ferais un fork plusieurs fois afin de faire évoluer chaque modules des projets universitaires.

Cette discussion a été vraiment intéressante pour l’organisation des projets futurs. Merci à tous :) .

+0 -0

Cette réponse a aidé l’auteur du sujet

L’approche mono-repo vs. multi-repo est pile un sujet sur lequel je bosse pour ma boîte.

Je rejoins ce qui s’est dit plus haut, les deux ont clairement leurs avantages et leurs inconvénients, et aucun n’est fondamentalement meilleur. Ce qui ferait la différence, si j’étais à ta place, c’est qu’en l’absence d’un tooling approprié (et qui n’existe pas à l’instant T en open source), il est très fastidieux de maintenir la cohérence et la compatibilité entre projets lorsqu’ils sont sur des repos séparés. Ça demande des systèmes d’intégration complexes, d’autant plus que la tentation est forte d’avoir des cycles de vie différents par repo (il faut alors gérer des matrices de compatibilité, et ça, clairement, c’est la merde).

Typiquement si tes deux projets partagent leur BDD, je partirais sans hésiter sur un mono-repo, pour avoir la garantie que sur un même commit, les deux projets parlent la même langue, ont le même schéma de BDD, et sont compatibles entre eux. Ça simplifie également le processus de release, les tests automatisés, l’intégration…

Certes l’historique git sera moins clean, mais si tu adoptes un minimum de rigueur sur les messages de commit (en prefixant chaque commit d’un [TAG EN MAJUSCULES] qui décrit le composant visé, par exemple), tu t’y retrouves à l’aise.

Tout ceci doit être tempéré, toutefois, par le fait que tu n’as visiblement que 2 composants. Si tu en avais 15 ou 30, ton choix aurait des conséquences beaucoup plus grandes.

Édité par nohar

I was a llama before it was cool

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte