GitHub de débutant à expert : un guide complet

1. Git et GitHub : Qui gère quoi ?

Git est un outil de gestion de versions installé sur votre ordinateur. Hors ligne, vous pouvez toujours effectuer des commits, consulter l'historique, créer des branches et fusionner. GitHub est une plateforme de dépôt distant et de collaboration ; il reçoit les commits poussés par Git et fournit Issues, Pull Requests, Actions, revues de code et gestion des autorisations.

Ce qui prête le plus à confusion dans Git, c'est qu'une même modification peut exister à quatre endroits différents. L'infographie ci-dessous décompose l'espace de travail, la zone de staging, le dépôt local et le dépôt distant en quatre couches.

Appuyer sur Enregistrer ne fait qu'écrire le contenu sur le disque dur. git add est responsable de la sélection, git commit laisse une version localement, et git push envoie ces commits sur GitHub.

Donc, avant de commiter, vérifiez le diff, exécutez-le ou testez-le ; après avoir poussé avec succès, retournez sur la page web pour une double vérification. Ainsi, si un problème survient, vous pouvez immédiatement savoir à quelle couche il s'est arrêté.

2. Avant de commencer : Préparez seulement quatre choses

Vous avez besoin de Git, d'un compte GitHub, d'un éditeur et d'un projet d'entraînement. VS Code suffit pour l'éditeur, et le projet peut être une page web ou un document Markdown.

D'abord, confirmez Git dans le terminal :

1git --version

Cet exercice utilise macOS et Git 2.49.0. Les utilisateurs Windows peuvent utiliser Git Bash ou le terminal intégré de VS Code ; les commandes Git ci-dessous sont les mêmes.

Ensuite, configurez l'auteur du commit :

1git config --global user.name "Votre Nom"
2git config --global user.email "Votre Email"

Ce sont les informations d'auteur écrites dans l'enregistrement du commit ; cela ne sert pas à se connecter à GitHub. Si vous voulez configurer uniquement pour le projet d'entraînement actuel, remplacez --global par --local.

La connexion à GitHub est une autre affaire. La ligne de commande utilise couramment trois méthodes :

• GitHub CLI, autorisation via navigateur avec gh auth login ;
• HTTPS, utilisant un Personal Access Token ou un gestionnaire d'identifiants ;
• SSH, ajoutant une clé publique à GitHub et s'authentifiant via la clé par la suite.

Les débutants peuvent choisir GitHub CLI ou HTTPS. Lors de l'utilisation de HTTPS, si le terminal demande un mot de passe, saisissez le Token ; les mots de passe de compte ordinaires ne sont plus applicables. N'écrivez pas le Token dans les commandes, les URL distantes, les README, les chats ou les captures d'écran.

3. Ne vous précipitez pas sur init : Confirmez d'abord où se trouve réellement le terminal

Cet exercice commence par une simple page web. Elle peut être ouverte dans un navigateur mais n'a pas encore d'historique Git.

Il y a trois fichiers dans le projet :

1index.html
2style.css
3.gitignore

Dans VS Code, sélectionnez "Ouvrir un dossier", ne cliquez pas simplement sur un fichier HTML. Exécutez ensuite dans le terminal intégré :

1pwd
2ls

pwd affiche le répertoire actuel, et ls liste les fichiers. Continuez seulement après avoir vu index.html et style.css.

Cette vérification semble stupide, mais elle évite le type d'accident le plus gênant : quelqu'un exécutant git init sur le Bureau, Documents, ou même le répertoire personnel de l'utilisateur, puis git add . mettant des milliers de fichiers non pertinents dans la zone de staging. Git n'est pas cassé ; le répertoire était faux.

4. Que fait git init ?

Maintenant, initialisez le dépôt :

1git init -b main
2git status --short

git init -b main crée un répertoire .git dans le dossier actuel et nomme la branche initiale main. .git est un répertoire caché où sont stockées les informations comme les commits, les branches, les zones de staging et les adresses distantes. Les fichiers du projet restent en place ; Git commence à les observer à partir de ce moment.

Le ?? dans la capture d'écran indique des fichiers non suivis. Les fichiers existent, mais Git n'a pas encore décidé s'il doit les enregistrer.

Pour confirmer le répertoire racine du dépôt, vous pouvez exécuter :

1git rev-parse --show-toplevel

La sortie doit être le dossier du projet actuel. Si elle indique fatal: not a git repository, vérifiez d'abord le répertoire, puis voyez si git init a été exécuté.

5. Le premier commit : Gardez un point de départ fiable

Le projet n'a pas encore été modifié, alors pourquoi commiter d'abord ? Parce que tous les changements ultérieurs ont besoin d'un point de départ comparable. D'abord, ouvrez la page web dans un navigateur pour confirmer que le titre, les cartes et la zone d'inscription s'affichent ; réduisez la fenêtre pour voir s'il y a un défilement horizontal à la largeur mobile.

Ensuite, regardez .gitignore. Le contenu utilisé cette fois est :

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

.gitignore sert à bloquer les clés, les logs, les dépendances et les artefacts de build. Il fonctionne principalement sur les fichiers qui ne sont pas encore suivis. Si une clé a déjà été commitée et que vous l'ajoutez ensuite à .gitignore, cet historique existe toujours ; le vrai traitement inclut également la révocation ou la rotation de la clé.

Commencez à sélectionner les fichiers pour le premier commit :

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

Le A dans le statut signifie Ajouté, indiquant que le fichier est entré dans la zone de staging. git diff --cached --stat vous indiquera combien de fichiers vous vous apprêtez à commiter et approximativement combien de lignes ont été modifiées. Pour voir le contenu spécifique, exécutez :

1git diff --cached

Commitez après confirmation :

1git commit -m "chore: Initialiser la page de recrutement IA du campus"
2git log --oneline
3git status

Un Commit peut être compris comme un instantané du projet avec auteur, heure, description et commit parent. ffdf4ff est la version courte du hash de ce commit ; l'utiliser dans le dépôt actuel permet de localiser précisément la version.

feat, fix, docs, style, chore sont des types de commit courants, pas une syntaxe Git obligatoire. Plus important que le préfixe est la description en français (ou en anglais) qui le suit : ce qui a été fait, quel objet a été modifié et pourquoi.

6. Le deuxième commit : Traitez les modifications IA comme des brouillons à réviser

Ensuite, ajoutez un bouton "Voir la méthode d'inscription" à la page. Lors de l'utilisation d'outils de programmation IA, j'écris les limites dans le prompt :

1Modifier uniquement index.html, ajouter un lien "Voir la méthode d'inscription" sous le texte d'introduction,
2pointant vers #apply dans la page. Ne pas modifier style.css, ne pas exécuter de commits Git.
3Dites-moi quel fichier a été modifié une fois terminé.

La modification manuelle est également simple :

1<a class="cta" href="#apply">Voir la méthode d'inscription</a>

L'IA dit que c'est fait, mais ne commitez pas encore. Exécutez :

1git status --short
2git diff -- index.html
3git diff --check

git diff montre les changements dans l'espace de travail qui n'ont pas encore été stagés. Le + vert est une ligne ajoutée, le - rouge est une ligne supprimée. git diff --check n'a pas de sortie, indiquant qu'aucun problème de formatage évident comme des espaces de fin n'a été trouvé ; il ne vérifiera pas si le bouton est cliquable pour vous.

Retournez dans le navigateur et actualisez, cliquez sur le bouton, puis réduisez la fenêtre. La page doit défiler jusqu'à la zone d'inscription, et le bouton et les cartes doivent rester normaux sur les écrans étroits.

Commitez seulement après que le test réussisse :

1git add index.html
2git diff --cached
3git commit -m "feat: Ajouter une entrée d'inscription pour visualiser rapidement les méthodes de candidature"
4git log --oneline -2

À ce stade, il y a deux versions claires dans le dépôt : la page de départ et le bouton d'inscription. Si le bouton a des problèmes plus tard, vous pouvez directement trouver quel commit l'a ajouté.

Au fait, distinguez les deux diffs :

1git diff             # Différence entre l'espace de travail et la zone de staging
2git diff --cached    # Différence entre la zone de staging et le commit le plus récent

Si git diff n'a pas de sortie, le fichier n'est peut-être pas enregistré, ou il a peut-être déjà été stagé ou commité. Vérifier git status, git diff --cached et git log dans l'ordre est plus fiable que de taper git add . à plusieurs reprises.

7. Branches : Laissez un espace de test pour les changements incertains

Le bouton n'ajoute qu'une seule ligne, donc le risque est faible. Changer tout le thème du violet à l'orange peut être beau ou peut être ringard ; ce genre de modification est adapté à une branche.

1git switch -c experiment/warm-theme
2git branch --show-current

Une branche est conceptuellement un nom pointant vers un certain commit. Lorsqu'une nouvelle branche est créée pour la première fois, elle pointe vers le même commit que main, donc les fichiers sont exactement les mêmes. Ce n'est que lorsque la branche expérimentale génère de nouveaux commits que les deux lignes divergent.

Dans le diagramme, le main bleu pointe toujours vers le deuxième commit, tandis que l'experiment orange pointe déjà vers le troisième commit. Le projet n'a pas dupliqué deux ensembles de fichiers ; seuls les pointeurs des deux noms de branche ont changé.

Modifiez les variables de couleur dans style.css, actualisez la page pour confirmer, puis commitez :

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: Essayer le thème chaud dans la branche expérimentale"
5git log --oneline --graph --decorate --all

HEAD indique où vous vous trouvez actuellement. Dans la capture d'écran, HEAD pointe vers experiment/warm-theme, tandis que main reste au commit du bouton.

Décidez de conserver le thème chaud, revenez à main et fusionnez :

1git switch main
2git merge experiment/warm-theme

Un Fast-forward se produit ici car main n'a pas eu de nouveaux commits pendant l'expérience. Git déplace directement le pointeur main vers l'avant jusqu'au commit du thème chaud ; les modifications ont été fusionnées avec succès.

Les branches fusionnées peuvent être supprimées en toute sécurité :

1git branch -d experiment/warm-theme

Le -d minuscule vérifie si la branche a été fusionnée. Le -D majuscule forcera la suppression, et les commits dans la branche qui n'ont pas été fusionnés pourraient perdre leurs références ; ne l'utilisez pas comme commande de nettoyage quotidien.

8. Les conflits ne sont pas mystérieux ; Git n'ose tout simplement pas choisir pour vous

Pour vérifier les conflits, j'ai dupliqué le dépôt. main a changé le titre principal en "Laissez la créativité du campus être vue par plus de personnes", et la branche feature a changé la même ligne en "Transformez une idée en un travail vraiment utilisable". Git s'est arrêté pendant la fusion :

Les marqueurs de conflit sont divisés en trois parties :

1<<<<<<< HEAD
2Contenu de la branche actuelle
3=======
4Contenu de la branche à fusionner
5>>>>>>> feature/rewrite-heading

La méthode de traitement consiste à éditer le fichier, laisser le texte final souhaité, supprimer les trois ensembles de marqueurs, le tester, puis exécuter :

1git add index.html
2git commit

Si vous ne voulez pas le traiter à ce moment-là, vous pouvez abandonner la fusion :

1git merge --abort

Un conflit signifie que deux personnes ou deux Agents ont donné des réponses différentes pour le même endroit, et Git ne peut pas choisir tout seul.

9. Envoyer le dépôt local vers GitHub

Le projet a déjà un historique local ; allez maintenant sur GitHub pour créer un dépôt. Cliquez sur le + dans le coin supérieur droit, sélectionnez "New repository", et remplissez le nom du dépôt, par exemple :

1campus-ai-demo

Pour la première pratique, il est recommandé de le mettre en Privé. Comme le local a déjà un README, .gitignore et un historique de commits, gardez le nouveau dépôt GitHub vide ; n'initialisez pas README, licence ou .gitignore côté web. Sinon, le local et le distant auront chacun un morceau d'historique initial, et le premier push nécessitera de gérer la relation entre les deux côtés d'abord. La documentation officielle de GitHub "Adding locally hosted code" le rappelle également explicitement.

Copiez l'adresse HTTPS :

1https://github.com/VotreNomUtilisateur/campus-ai-demo.git

Retournez au terminal du projet :

1git remote add origin https://github.com/VotreNomUtilisateur/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin est un alias pour l'adresse distante ; il peut fonctionner avec d'autres noms, mais la communauté appelle habituellement le dépôt distant principal origin. -u établira une relation de suivi entre le main local et origin/main ; les opérations ultérieures consistent généralement à exécuter git push.

Le diagramme du terminal ci-dessous a utilisé un dépôt nu local pour exécuter push et clone, donc il n'a pas modifié le compte GitHub existant. Lors du passage à GitHub, remplacez simplement l'URL origin ; la logique pour que Git transmette les commits et établisse les relations de suivi est la même.

Une fois le vrai push terminé, retournez sur la page web GitHub et actualisez pour confirmer que les fichiers, le README, la branche par défaut et l'historique des commits sont tous visibles. Le message de succès dans le terminal est une couche de preuve, et la vérification web en est une autre.

10. Lire un dépôt GitHub pour la première fois : Comment lire ces choses sur la page

Ci-dessous se trouve la vraie page du dépôt de documentation officielle de GitHub, capturée d'écran le 15 août 2026.

En ouvrant un dépôt, regardez d'abord ces endroits :

• Code : Fichiers, répertoires, branches et commits ;
• Issues : Bugs, exigences, tâches et discussions ;
• Pull requests : Changements en attente de révision ou de fusion ;
• Actions : Tests automatisés, construction et déploiement ;
• Security : Politiques de sécurité et fonctions liées aux vulnérabilités ;
• Insights : Contributions, trafic et activité du dépôt ;
• README : Présentation du projet et entrée d'utilisation ;
• LICENSE : Comment il est autorisé à être utilisé, modifié et distribué.

En lisant un projet inconnu, ne regardez pas d'abord les Stars. Répondez d'abord à cinq questions : Quel problème résout-il, comment s'exécute-t-il, de quoi dépend-il, est-il récemment maintenu, et que m'autorise la licence à faire. Les Stars reflètent l'attention ; elles ne vérifient pas la sécurité, la compatibilité ou l'autorisation pour vous.

11. clone, fetch, pull, push : Ne confondez pas les quatre directions

Prendre un dépôt distant sur votre ordinateur pour la première fois :

1git clone https://github.com/PROPRIÉTAIRE/DÉPÔT.git

Clone ramène les fichiers, l'historique des commits et les configurations distantes, nommant généralement automatiquement le dépôt distant origin. Télécharger un ZIP ne donne qu'un instantané des fichiers à ce moment-là, sans historique complet, et n'établira pas de relation distante.

Les trois actions couramment utilisées ensuite sont :

1git fetch origin   # Télécharge les informations distantes, ne modifie pas les fichiers de travail actuels
2git pull           # fetch puis intègre dans la branche actuelle
3git push           # Envoie les commits locaux vers le distant

Pour voir d'abord ce qui s'est passé à distance, vous pouvez :

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

Lorsque vous confirmez qu'il n'y a pas de divergence localement et que vous souhaitez n'accepter que les mises à jour fast-forward :

1git pull --ff-only

pull fera d'abord fetch, puis effectuera merge ou rebase selon la configuration. Les équipes doivent se mettre d'accord sur la méthode d'intégration avant la première collaboration, et ne comptez pas sur force push pour aplanir les problèmes en cas de divergence.

12. Du dépôt personnel à la collaboration GitHub

Une Pull Request est une proposition de fusion et l'endroit où la collaboration se produit. Les discussions, les revues de code et les vérifications automatisées tournent toutes autour du même ensemble de changements, et il est fusionné dans main seulement après confirmation.

En supposant que l'Issue soit "Ajouter la description de l'heure de l'événement", les opérations locales peuvent être faites comme ceci :

1git switch -c feat/event-time
2# Modifier et tester la page
3git add index.html
4git commit -m "feat: Ajouter la description de l'heure de l'événement"
5git push -u origin feat/event-time

Après avoir poussé, GitHub invite généralement à créer une Pull Request. Une PR est une proposition de fusion qui affiche les descriptions, les commits, les différences de fichiers, les commentaires, les revues et les vérifications automatisées. Elle n'entrera pas automatiquement dans main simplement parce qu'elle a été créée.

Une PR que les gens sont prêts à réviser doit expliquer au moins trois choses : ce qui a été changé, pourquoi cela a été changé et comment le vérifier. Plus les changements sont ciblés, plus il est facile pour les réviseurs de repérer les problèmes.

Dans la même équipe, si vous avez un accès en écriture au dépôt, vous pouvez envoyer une PR directement depuis une branche. Lorsque vous contribuez à un projet open source inconnu, la pratique courante est de d'abord le Forker sur votre propre compte, puis de cloner votre propre Fork :

1git clone https://github.com/VotreNomUtilisateur/NomDuProjet.git
2cd NomDuProjet
3git remote add upstream https://github.com/AuteurOriginal/NomDuProjet.git
4git remote -v

Il y a généralement deux dépôts distants ici :

1origin    Votre propre Fork
2upstream  Le dépôt de l'auteur original

Synchronisez le projet original :

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

Ensuite, effectuez les modifications dans une nouvelle branche, poussez vers votre propre Fork, puis envoyez une PR vers upstream. Fork, clone et branche résolvent trois choses différentes : Fork est un ensemble d'espace de dépôt sur GitHub, clone amène le dépôt en local, et branche est une ligne de développement au sein d'un dépôt.

13. README et LICENSE déterminent si les autres osent l'utiliser

Un README doit répondre au moins à ces questions :

1. Qu'est-ce que le projet ;
2. Quel problème résout-il ;
3. Comment l'installer ou l'exécuter ;
4. Dans quelle mesure est-il actuellement terminé ;
5. Où se trouvent les principaux fichiers ;
6. Qui sont les auteurs, les matériaux et les sources de citation.

Si le code peut s'exécuter mais que le README est vague, vous pourriez ne pas être capable de le reprendre vous-même trois mois plus tard. Un README minimal n'a pas besoin d'être joli ; écrivez simplement clairement le projet, la méthode d'exécution et le statut.

Les dépôts publics n'équivalent pas non plus automatiquement à l'obtention d'une licence open source. L'explication officielle de la licence par GitHub indique clairement : lorsqu'il n'y a pas de licence, les règles de copyright par défaut s'appliquent toujours, et l'auteur conserve les droits de copie, de distribution et de création d'œuvres dérivées. Public signifie que les autres peuvent le voir et le Forker selon les conditions d'utilisation de GitHub ; pour prendre le code dans votre propre projet public ou commercial, vous devez également regarder la LICENCE dans le dépôt.

MIT, Apache-2.0, GPL, etc., ont des obligations différentes. Lorsque vous rencontrez une utilisation commerciale, une redistribution ou des licences mixtes, lisez le fichier complet et consultez un professionnel si nécessaire ; ne demandez pas simplement à une IA "Puis-je l'utiliser à des fins commerciales ?"

14. Après avoir fait une erreur : Déterminez à quelle couche se trouve le changement

Le remède contre les regrets doit être choisi en fonction de l'état.

Fichier stagé par erreur mais vous voulez conserver le contenu du fichier :

1git restore --staged nom_du_fichier

Le message du commit le plus récent a été mal écrit et n'a pas encore été poussé :

1git commit --amend -m "Nouveau message de commit"

Un commit sur une branche partagée doit être révoqué :

1git revert hash_du_commit

revert produira un nouveau commit inverse, et l'ancien historique reste visible, ce qui est adapté aux branches qui ont déjà été poussées et sont utilisées par plusieurs personnes.

git restore nom_du_fichier annulera les modifications qui n'ont pas été commitées ; git reset --hard fera revenir les commits, la zone de staging et l'espace de travail à une position spécifiée ; git push --force peut écraser les commits distants. Ces trois types d'opérations nécessitent une confirmation de la cible et une sauvegarde avant exécution ; ne les traitez pas comme des boutons de réparation généraux au stade zéro-base.

15. Les huit erreurs les plus courantes : Vérifiez dans cet ordre

1. fatal: not a git repository

1pwd
2ls
3git status

Habituellement, le répertoire est faux, ou le projet actuel n'a pas encore été git init.

2. Author identity unknown

1git config --local user.name "Votre Nom"
2git config --local user.email "Votre Email"

3. nothing to commit

Vérifiez si le fichier est enregistré, si vous avez modifié une autre copie, et si les modifications ont déjà été commitées :

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin AdresseGitHubCorrecte

5. src refspec main does not match any

Le dépôt n'a peut-être pas encore de commit, ou la branche actuelle ne s'appelle pas main :

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

Vérifiez l'URL distante, la propriété du dépôt, les autorisations du compte et la méthode d'authentification. N'envoyez pas le Token à d'autres pour le dépannage.

7. rejected non-fast-forward

Il y a des commits distants qui ne sont pas locaux. Récupérez et visualisez d'abord les différences ; ne forcez pas le push tout de suite :

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

Exécutez git status pour trouver les fichiers UU, déterminez manuellement le contenu final, testez, puis add et commit ; si vous ne le traitez pas pour l'instant, git merge --abort.

Lorsqu'un étudiant ou un collègue dit simplement « Git est cassé », demandez-lui de fournir ces cinq sorties :

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

Ajoutez ensuite le système d'exploitation, la commande complète qui vient d'être exécutée et le message d'erreur complet. La plupart des problèmes se classeront rapidement dans l'une des couches : répertoire, statut, identité, adresse distante ou autorisation.

16. À l'ère de l'IA, Git est davantage un système d'acceptation

L'IA peut taper des commandes à votre place, mais elle ne peut pas savoir automatiquement quelles modifications correspondent aux intentions métier. Si une invite modifie 20 fichiers et que vous ne regardez pas le diff, n'exécutez pas le projet et ne vérifiez pas les clés, Git se contentera d'enregistrer fidèlement ce désordre.

Une approche plus stable consiste à réduire la tâche et à placer l'humain en position d'acceptation. Une fois que la portée, les différences, les tests et les vérifications des clés sont tous validés, l'humain décide si ces modifications peuvent devenir un commit.

Lorsque vous laissez l'IA opérer Git, donnez-lui aussi des limites :

1Veuillez d'abord vérifier git status et git diff, et résumez uniquement les modifications en cours.
2Ne supprimez aucun contenu non commité, n'exécutez pas reset --hard, clean ou force push.
3Fournissez les résultats de vérification après avoir terminé les modifications, ne commitez pas et ne pushez pas automatiquement.

Savoir mémoriser des commandes n'est plus si important. Vous devez être capable de lire le statut, de savoir ce que l'IA a déplacé, de juger si la vérification est suffisante et d'arrêter lorsque des opérations dangereuses apparaissent.

17. Repassez tout le processus

1# 1. Confirmer l'emplacement
2pwd
3ls
4
5# 2. Initialiser
6git init -b main
7git status
8
9# 3. Premier commit
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Initialiser le projet"
13
14# 4. Modifier, vérifier, tester, recommiter
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Ajouter l'entrée d'inscription"
20
21# 5. Expérience de branche
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Expérimenter le thème chaud"
25git switch main
26git merge experiment/warm-theme
27
28# 6. Connexion à GitHub
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. Vérification finale
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

Lorsque vous pouvez expliquer quelle couche chaque commande a modifiée et que vous pouvez gérer indépendamment un mauvais répertoire, une erreur de staging et un conflit de fusion, GitHub n'est plus seulement un site web pour stocker du code. Vous êtes déjà capable de transformer des projets personnels en dépôts pouvant être examinés, audités et collaboratifs.

La prochaine étape ne nécessite pas de continuer à collectionner des commandes. Trouvez un vrai petit projet et faites-le pendant 7 jours consécutifs : effectuez une seule petite modification chaque jour, regardez le diff, testez, commitez, puis pushez sur GitHub. L'historique des commits transformera lentement cet ensemble de choses en votre habitude de travail.

Je suis Miles, un expert en algorithmes d'IA passé d'une grande entreprise à FDE. J'ai fait de la R&D en algorithmes, du déploiement d'optimisation et de la formation en entreprise. Suivez-moi @miles_mazy Grandissons ensemble, gagnons de l'argent ensemble.