Tous les mots que les devs utilisent pour avoir l'air smart — traduits en humain.
Clique sur un terme pour aller à sa définition ↓
Tu connais Finder ? Avec ses belles icônes et ses dossiers colorés ?
Le terminal, c'est la même chose, mais pour les gens qui trouvent que les icônes c'est trop fancy.
C'est une fenêtre où tu tapes des commandes texte pour parler directement à ton ordi — sans cliquer sur quoi que ce soit.
Imagine Google Docs, mais pour du code. Tout le monde travaille sur le même projet, et Git s'assure que personne écrase le travail des autres.
design-FINAL.psd
design-FINAL-v2.psd
design-FINAL-FINAL.psd
design-VRAIEMENT-FINAL.psd
Un seul fichier.
Historique complet.
Tout le monde synchronisé.
Zéro confusion.
Git garde un historique de tous les changements. Tu peux revenir en arrière à n'importe quel moment. C'est le filet de sécurité ultime.
C'est le dossier cloud de ton projet. Pense à Google Drive, mais pour du code. C'est là que tous les fichiers du projet vivent.
Repo = raccourci de repository. Quand quelqu'un dit « le repo », il parle du dossier principal du projet sur GitHub.
Imagine un papier calque. Tu dessines dessus pour tester des idées, et si c'est bon, tu traces sur le vrai dessin. Si c'est nul, tu jettes le calque.
La version « officielle » du projet. Le vrai dessin. On y touche pas n'importe comment.
Ta copie personnelle. Tu expérimentes là-dessus. Si tes changements sont bons, on les « merge ».
C'est Ctrl+S + un post-it de ce que t'as changé. Tu sauvegardes ton travail ET tu écris une petite note qui explique pourquoi.
Sauvegarde tes fichiers modifiés
Le message qui dit ce que t'as fait
Tu pourras revenir ici si ça foire
(Pull Request)
C'est comme envoyer ton Figma pour review avant de l'officialiser. Tu dis à l'équipe : « J'ai fait des changements, checkez svp ».
Tu envoies ton travail sur le cloud (GitHub)
Tu demandes une review à l'équipe
L'équipe valide (ou demande des changements)
C'est un filet de sécurité : quelqu'un d'autre regarde ton code avant qu'il aille dans le « vrai » projet. Comme un deuxième regard sur un contrat.
Ton brouillon a été approuvé ? On le colle sur le vrai projet. Ta branch rejoint la branch principale. Mariage officiel.
Ta branch + Main = le projet mis à jour
C'est le bouton Publish, mais pour du code. Ton travail passe du brouillon au monde réel. Les vrais utilisateurs voient tes changements.
Là où tu codes
Un ordi dans le cloud qui fait tourner ton app
Les vrais utilisateurs voient le résultat
Pense à un restaurant. La salle à manger c'est le frontend. La cuisine c'est le backend.
Ce que le client voit : la déco, les assiettes, le menu. En dev : les boutons, les couleurs, les animations, le design.
Ce qui se passe en coulisses : la cuisine, les commandes, le frigo. En dev : la base de données, les calculs, la sécurité.
Le serveur du restaurant. Il prend ta commande (frontend), l'amène en cuisine (backend), et revient avec ton plat.
« Je veux les données du profil utilisateur »
Prend la demande, va chercher l'info, revient avec la réponse
Prépare les données demandées
API = Application Programming Interface. C'est juste un système de communication entre deux parties d'une app. Le frontend demande, l'API livre.
Le classeur géant où toutes les infos sont rangées. Noms d'utilisateurs, commandes, historique — tout est là.
Chaque app a une base de données. Quand tu te connectes, quand tu fais une recherche, quand tu passes une commande — l'info vient de là. C'est la mémoire de l'app.
Les 3 versions de ton projet. Comme au théâtre : brouillon, répétition, et le vrai show.
Le brouillon.
Ton ordi local. Tu expérimentes. Rien de visible publiquement. Tu peux tout casser, personne voit.
La répétition.
Une copie quasi-identique au vrai site. L'équipe teste là avant de publier pour de vrai.
Le vrai show.
Le site que les vrais utilisateurs voient. On ne touche à ça qu'après avoir testé en staging.
Le cheat sheet officiel :
Made with 🫶 (et un peu de trauma)