SkyMinds.Net

Git — et son homologue GitHub — permet de versionner votre code afin de suivre les changements, commenter les modifications, revenir en arrière, collaborer avec d’autres développeurs, gérer une feuille de route, ouvrir des issues et accepter des pull requests.

En clair : Git garde l’historique de votre projet, tandis que GitHub héberge ce projet en ligne et facilite la collaboration.

Voici un mémo pratique pour créer un dépôt Git local, y ajouter du code, le connecter à GitHub, puis envoyer les changements sur le dépôt distant.

Installer Git

Commençons par l’étape obligatoire : installer Git sur votre système.

• Git pour macOS
• Git pour Linux
• Git pour Windows

Sous Ubuntu ou Debian, on peut l’installer avec :

sudo apt update
sudo apt install git

Sous macOS avec Homebrew :

brew install git

Pour vérifier que Git est bien installé :

git --version

Configurer son identité Git

Avant de créer vos premiers commits, configurez votre nom et votre adresse email. Git les utilisera dans l’historique du projet.

git config --global user.name "Matt Biscay"
git config --global user.email "matt@example.com"Code language: PHP (php)

Vous pouvez vérifier la configuration avec :

git config --global --listCode language: PHP (php)

Si vous travaillez sur plusieurs identités, par exemple une adresse personnelle et une adresse professionnelle, vous pouvez aussi configurer ces valeurs localement dans un projet précis :

git config user.name "Matt Biscay"
git config user.email "matt@example.com"Code language: CSS (css)

Sans l’option --global, la configuration s’applique uniquement au dépôt courant.

macOS : résoudre l’erreur xcrun invalid active developer path

Sous macOS, après une mise à jour du système, une commande Git peut afficher cette erreur :

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools),
missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrunCode language: JavaScript (javascript)

Cela signifie généralement que les outils en ligne de commande de Xcode sont absents ou cassés.

On peut les réinstaller avec :

sudo rm -rf /Library/Developer/CommandLineTools
sudo xcode-select --install

Ensuite, relancez le terminal et vérifiez :

git --version

Créer un dépôt Git local

Placez-vous dans le répertoire qui contient votre code :

cd /chemin/vers/mon-projet

Initialisez ensuite le dépôt Git :

git init

Cette commande crée un dossier caché .git dans le projet. C’est là que Git stocke l’historique, les branches, les références et les objets internes du dépôt. La documentation officielle indique que git init crée un dépôt vide, notamment avec un répertoire .git et les sous-dossiers nécessaires.

On peut vérifier l’état du dépôt avec :

git status

Créer un fichier .gitignore

Avant d’ajouter tous les fichiers, créez un fichier .gitignore. Il permet d’indiquer à Git ce qu’il ne doit pas versionner : caches, dépendances installées, fichiers temporaires, secrets, exports, archives, logs ou fichiers générés.

Pour un projet PHP ou WordPress, on peut commencer avec ceci :

# Dépendances.
vendor/
node_modules/

# Environnement local.
.env
.env.*
!.env.example

# Logs.
*.log
logs/

# Fichiers système.
.DS_Store
Thumbs.db

# Archives et sauvegardes.
*.zip
*.tar
*.tar.gz
*.sql
*.sql.gz

# WordPress.
wp-config.php
wp-content/cache/
wp-content/uploads/cache/
wp-content/upgrade/
wp-content/backup*/
wp-content/backups/
wp-content/debug.logCode language: PHP (php)

Le contenu exact dépend du projet. Par exemple, sur un plugin WordPress public, vous versionnerez probablement le code source du plugin, mais pas les exports de build, les dépendances locales ou les fichiers sensibles.

Un bon .gitignore évite de pousser un wp-config.php, un dump SQL ou un fichier .env sur GitHub. Oui, cela arrive. Non, ce n’est jamais un bon moment.

Créer un fichier README

Un dépôt sans README.md oblige les visiteurs à deviner ce que fait le projet. Autant éviter cette petite loterie.

# Mon projet

Description courte du projet.

## Installation

```bash
composer install
npm install

## Utilisation
Expliquez ici comment utiliser le projet.
Code language: PHP (php)

Le README n’a pas besoin d’être parfait au départ. Il doit surtout expliquer à quoi sert le projet, comment l’installer, comment le lancer et quelles commandes importantes connaître.

Ajouter les fichiers au dépôt

Pour voir les fichiers détectés par Git :

git status

Pour ajouter tous les fichiers modifiés, créés ou supprimés :

git add -A

Je préfère git add -A à git add *, car git add -A tient aussi compte des suppressions et des fichiers cachés pertinents. git add * dépend davantage du shell et peut oublier certains fichiers. Le genre de détail discret qui finit en “mais pourquoi mon fichier n’est pas sur GitHub ?”.

Pour ajouter un fichier précis :

git add chemin/vers/fichier.php

Pour ajouter uniquement une partie des changements d’un fichier, utilisez le mode interactif :

git add -p

C’est très pratique pour créer des commits propres et séparés.

Créer le premier commit

Une fois les fichiers ajoutés, on valide les changements avec un commit :

git commit -m "Initial commit"Code language: JavaScript (javascript)

Un commit doit représenter une unité logique de changement. Évitez les messages du type update, fix ou test si vous voulez comprendre l’historique dans six mois.

Quelques exemples plus utiles :

git commit -m "Add plugin bootstrap file" git commit -m "Add Composer autoloader" git commit -m "Fix checkout validation" git commit -m "Remove unused admin CSS"Code language: JavaScript (javascript)

Le commit n’envoie rien sur GitHub. Il enregistre seulement l’état du code dans votre dépôt local.

Utiliser main plutôt que master

Les dépôts récents utilisent généralement main comme branche principale. Si votre dépôt local a créé une branche master, vous pouvez la renommer :

git branch -M main

GitHub utilise également main dans ses instructions modernes pour pousser un dépôt local vers GitHub.

Créer un dépôt sur GitHub

Créez maintenant un nouveau dépôt sur GitHub.

Si vous poussez un projet local existant, évitez d’initialiser le dépôt GitHub avec un README, une licence ou un fichier .gitignore. GitHub le recommande aussi pour éviter des erreurs ou conflits lors du premier push.

Une fois le dépôt créé, copiez son URL. Elle ressemblera à ceci en HTTPS :

https://github.com/OWNER/REPOSITORY.gitCode language: JavaScript (javascript)

Ou à ceci en SSH :

git@github.com:OWNER/REPOSITORY.git

Associer le dépôt local au dépôt GitHub

Dans le dossier du projet, ajoutez le dépôt distant avec git remote add :

git remote add origin https://github.com/OWNER/REPOSITORY.gitCode language: JavaScript (javascript)

GitHub explique que git remote add prend deux arguments : un nom de remote, par exemple origin, et une URL de dépôt distant.

Pour vérifier le remote :

git remote -v

Si vous vous êtes trompé d’URL, corrigez-la avec :

git remote set-url origin https://github.com/OWNER/REPOSITORY.gitCode language: JavaScript (javascript)

Envoyer le code sur GitHub

Pour envoyer votre branche locale main vers GitHub :

git push -u origin main

L’option -u définit une relation de suivi entre la branche locale main et la branche distante origin/main. Ensuite, vous pourrez simplement utiliser :

git push

Pour les futurs changements, le cycle classique devient :

git status git add -A git commit -m "Describe the change" git pushCode language: JavaScript (javascript)

HTTPS, token personnel ou SSH ?

Avec GitHub, l’authentification par mot de passe classique ne suffit plus pour les opérations Git en ligne de commande. GitHub recommande d’utiliser un token personnel à la place du mot de passe, ou une autre méthode d’authentification moderne.

Vous avez donc deux options courantes.

Option 1 : HTTPS avec token personnel

Le remote ressemble à ceci :

https://github.com/OWNER/REPOSITORY.gitCode language: JavaScript (javascript)

Au moment du push, GitHub peut vous demander un identifiant et un mot de passe. L’identifiant est votre nom d’utilisateur GitHub. Le “mot de passe” doit être un token personnel, pas le mot de passe de votre compte.

Cette méthode est simple, surtout avec un gestionnaire d’identifiants Git.

Option 2 : SSH

Le remote ressemble à ceci :

git@github.com:OWNER/REPOSITORY.git

SSH est très confortable sur une machine de développement ou un serveur de déploiement. Une fois la clé SSH ajoutée à GitHub, les push et pull deviennent plus fluides.

Pour changer un dépôt existant de HTTPS vers SSH :

git remote set-url origin git@github.com:OWNER/REPOSITORY.gitCode language: JavaScript (javascript)

Pour tester l’accès SSH :

ssh -T git@github.comCode language: CSS (css)

Récupérer les changements depuis GitHub

Pour récupérer les dernières modifications du dépôt distant :

git pull

Attention à la formulation classique “cela écrase les fichiers locaux” : ce n’est pas exactement ce que fait git pull. En réalité, git pull récupère les changements distants, puis tente de les intégrer à votre branche locale. Si vos changements locaux entrent en conflit avec les changements distants, Git vous demandera de résoudre le conflit.

Pour voir ce qui existe sur le dépôt distant sans intégrer les changements immédiatement :

git fetch

Puis comparez :

git status git log --oneline --graph --decorate --all

Pour un workflow plus prudent, j’aime bien faire :

git fetch git status git pull --rebase

Le rebase garde souvent un historique plus linéaire, mais il faut l’utiliser avec un minimum de discipline. Git est un excellent outil, pas un bouton magique.

Créer une branche pour travailler proprement

Pour un petit mémo personnel, travailler directement sur main peut suffire. Pour un vrai projet, il vaut mieux créer une branche par fonctionnalité ou correction.

git switch -c fix-checkout-validationCode language: JavaScript (javascript)

Ajoutez ensuite vos changements :

git add -A git commit -m "Fix checkout validation" git push -u origin fix-checkout-validationCode language: JavaScript (javascript)

Vous pouvez ensuite ouvrir une pull request sur GitHub pour relire, discuter et fusionner les changements.

Pour revenir sur la branche principale :

git switch mainCode language: JavaScript (javascript)

Pour supprimer la branche locale une fois fusionnée :

git branch -d fix-checkout-validation

Voir l’historique du projet

Pour afficher l’historique simple :

git log --oneline

Pour un affichage plus utile avec les branches :

git log --oneline --graph --decorate --all

Pour voir les changements non commités :

git diff

Pour voir les changements déjà ajoutés avec git add :

git diff --cached

Annuler une erreur courante

Git permet de revenir en arrière, mais il faut choisir la bonne commande selon le cas.

Pour retirer un fichier de la zone d’index sans supprimer ses modifications :

git restore --staged fichier.phpCode language: CSS (css)

Pour annuler les modifications locales d’un fichier non commitées :

git restore fichier.phpCode language: CSS (css)

Pour modifier le dernier commit, par exemple après avoir oublié un fichier :

git add fichier-oublie.php git commit --amendCode language: CSS (css)

Pour créer un commit qui annule un commit précédent, sans réécrire l’historique :

git revert HASH_DU_COMMIT

Sur une branche déjà partagée, git revert est souvent plus sûr que git reset, car il conserve un historique explicite.

Cas pratique : envoyer un projet local existant sur GitHub

Voici la séquence complète pour un projet déjà présent sur votre machine :

cd /chemin/vers/mon-projet git init git branch -M main git status git add -A git commit -m "Initial commit" git remote add origin https://github.com/OWNER/REPOSITORY.git git push -u origin mainCode language: JavaScript (javascript)

Avec SSH :

cd /chemin/vers/mon-projet git init git branch -M main git add -A git commit -m "Initial commit" git remote add origin git@github.com:OWNER/REPOSITORY.git git push -u origin mainCode language: JavaScript (javascript)

C’est le workflow moderne le plus courant pour publier un projet local existant sur GitHub.

Cas pratique : cloner un dépôt GitHub existant

Si le dépôt existe déjà sur GitHub, le plus simple est de le cloner :

git clone https://github.com/OWNER/REPOSITORY.gitCode language: PHP (php)

Ou avec SSH :

git clone git@github.com:OWNER/REPOSITORY.gitCode language: PHP (php)

Puis entrez dans le dossier :

cd REPOSITORY

À partir de là, le remote origin est déjà configuré.

Cas WordPress : que versionner ?

Pour un site WordPress classique, on évite généralement de versionner tout le répertoire WordPress en vrac. Mieux vaut versionner ce que vous développez réellement.

Par exemple :

• un thème personnalisé ;
• un thème enfant ;
• un plugin maison ;
• un mu-plugin ;
• un fichier de configuration de déploiement ;
• les sources Sass, CSS, JS ou build d’un projet.

En revanche, on évite de versionner :

• wp-config.php ;
• les uploads ;
• les caches ;
• les sauvegardes ;
• les exports SQL ;
• les fichiers contenant des secrets.

Pour un plugin WordPress public, GitHub peut servir de dépôt de développement, tandis que WordPress.org SVN reste le canal de publication officiel. Pour un plugin privé, GitHub suffit souvent très bien.

Ajouter un fichier .gitattributes

Un fichier .gitattributes permet de contrôler certains comportements Git, notamment les fins de ligne, les exports ou les archives.

Exemple simple pour un projet PHP :

* text=auto *.php text eol=lf *.css text eol=lf *.js text eol=lf *.json text eol=lf *.md text eol=lf *.png binary *.jpg binary *.jpeg binary *.gif binary *.webp binary *.avif binary

C’est particulièrement utile si plusieurs développeurs travaillent sur Windows, macOS et Linux. Les fins de ligne ne deviennent plus un festival discret de diffs inutiles.

Mémo rapide des commandes Git essentielles

# Vérifier la version de Git. git --version # Configurer son identité. git config --global user.name "Votre nom" git config --global user.email "email@example.com" # Initialiser un dépôt. git init # Renommer la branche principale en main. git branch -M main # Voir l’état du dépôt. git status # Ajouter tous les changements. git add -A # Créer un commit. git commit -m "Message clair" # Ajouter GitHub comme dépôt distant. git remote add origin https://github.com/OWNER/REPOSITORY.git # Vérifier les dépôts distants. git remote -v # Envoyer le code sur GitHub. git push -u origin main # Envoyer les prochains changements. git push # Récupérer les changements distants. git pull # Récupérer sans intégrer immédiatement. git fetch # Créer une branche. git switch -c nom-de-branche # Revenir sur main. git switch main # Voir l’historique. git log --oneline --graph --decorate --allCode language: CSS (css)

Conclusion

Pour envoyer un projet local sur GitHub, le workflow moderne tient en quelques commandes :

git init git branch -M main git add -A git commit -m "Initial commit" git remote add origin https://github.com/OWNER/REPOSITORY.git git push -u origin mainCode language: JavaScript (javascript)

Ensuite, le cycle quotidien reste très simple : modifier le code, vérifier avec git status, ajouter avec git add -A, valider avec git commit, puis envoyer avec git push.

Une fois ces bases maîtrisées, vous pouvez passer aux branches, pull requests, tags, releases, hooks, GitHub Actions et déploiements automatisés. Mais même avec ce simple mémo, vous avez déjà de quoi arrêter de renommer des dossiers en projet-final-v3-vraiment-final.zip. Progrès civilisationnel évident.