Projets composés de plusieurs catégories

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.

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.

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.

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

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

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

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.