Git pour développeurs : de l’init au déploiement

Chaque développeur connaît ce sentiment : tu as travaillé pendant des heures sur une fonctionnalité, tu sauvegardes, et puis quelque chose tourne mal. Le serveur de production fait tourner une version que tu ne reconnais plus, un collègue a entre-temps apporté des modifications qui entrent en conflit avec ton code, et tu n'as aucune idée de quelle version est réellement « la bonne ». C'est exactement le problème que Git résout — et pourquoi tout développeur sérieux travaille avec au quotidien.

Git est le système de gestion de versions le plus utilisé au monde. Il te permet de suivre les modifications, de collaborer sans écraser le travail des autres, et de déployer en production en toute confiance. Dans cet article, tu parcours le workflow Git complet : du tout premier git init jusqu'à un déploiement simplifié. Pratique, concret et directement applicable.

Les bases : configurer un dépôt avec git init

Tout commence avec un dépôt. Un dépôt Git est simplement un dossier dans lequel Git suit toutes les modifications. Tu en crées un avec une seule commande :

git init mijn-project

Cela crée un nouveau dossier contenant un dossier caché .git — le cœur de ton dépôt. Tu travailles déjà dans un dossier de projet existant ? Alors tu initialises Git directement sur place :

cd mijn-project
git init

Ensuite, tu relies un dépôt distant, par exemple sur GitHub ou GitLab :

git remote add origin https://github.com/gebruiker/mijn-project.git

Ton environnement local est maintenant connecté à un emplacement central. C'est la base de toute collaboration et de tout déploiement.

Avant de faire ton premier commit, il est judicieux de créer un fichier .gitignore. Ce fichier indique à Git quels fichiers ne doivent pas être suivis — pense à node_modules/, aux fichiers .env contenant des mots de passe, ou aux artefacts de compilation. GitHub et GitLab proposent des modèles .gitignore prêts à l'emploi par type de langage.

Commits, branches et le workflow quotidien

Le cœur de Git tourne autour des commits. Un commit est un instantané de ton code à un moment donné. Tu ajoutes des fichiers à la zone dite de staging et ensuite tu sauvegardes cet instantané :

git add index.php
git commit -m "Voeg contactformulier toe aan homepage"

Tu veux ajouter tous les fichiers modifiés en une seule fois ?

git add .
git commit -m "Initiële projectstructuur"

Écris toujours des messages de commit significatifs. "Fix bug" ne dit rien. "Los race condition op in login-handler bij gelijktijdige sessies" dit tout. Ton futur toi-même — et tes collègues — t'en seront reconnaissants.

Branches : travailler en parallèle sans conflits

Les branches sont l'une des fonctionnalités les plus puissantes de Git. Elles te permettent de travailler sur une fonctionnalité ou une correction de bug sans toucher à la branche principale (main ou master). L'approche standard :

git checkout -b feature/gebruikerslogin

Tu travailles maintenant sur une branche séparée. Fais des commits, teste localement, et ensuite seulement tu fusionnes vers main. Tu veux une stratégie de branche structurée ? Alors Git Flow est une approche éprouvée :

git flow init

Git Flow introduit des noms de branches fixes pour les fonctionnalités, les versions et les correctifs urgents. C'est un peu plus élaboré, mais pour les équipes avec des versions régulières, c'est une excellente structure. Démarre une nouvelle fonctionnalité ainsi :

git flow feature start gebruikerslogin

Et termine-la avec :

git flow feature finish gebruikerslogin

Pour les projets plus petits ou le travail en solo, une approche simple avec main + branches de fonctionnalités est plus que suffisante.

Collaborer via les pull requests et les merge requests

Lorsque tu as terminé une fonctionnalité, tu veux que ce code soit revu avant qu'il n'aille sur main. Cela se fait via un pull request (GitHub) ou un merge request (GitLab). Ce n'est pas seulement une étape technique — c'est un contrôle de qualité.

Via la CLI GitHub, tu crées un pull request directement depuis ton terminal :

gh pr merge

Cette commande fusionne le pull request lié à ta branche actuelle, de manière interactive. Tu choisis toi-même si tu veux fusionner, squasher ou rebaser. Les utilisateurs de GitLab font de même avec :

glab mr merge

Tu veux créer un merge request pour une revue, alors tu utilises :

glab mr create

Le processus de revue t'oblige à examiner le code consciemment. Les petites équipes sautent parfois cette étape, mais même en travaillant en solo, un pull request est utile : cela t'oblige à réfléchir à ce que tu as exactement modifié avant que cela n'arrive en production.

Résoudre les conflits

Les conflits de fusion semblent effrayants, mais ils sont normaux. Ils surviennent lorsque deux branches ont modifié les mêmes lignes différemment. Git marque les sections conflictuelles dans ton fichier :

<<<<<<< HEAD
echo "Versie A";
=======
echo "Versie B";
>>>>>>> feature/nieuwe-functie

C'est toi qui décides quelle version gagne, ou tu combines les deux. Ensuite, tu ajoutes le fichier et tu fais un commit :

git add conflict-bestand.php
git commit -m "Los merge-conflict op in uitvoerfunctie"

Du commit au déploiement : CI/CD avec GitHub Actions

Un bon workflow Git ne s'arrête pas à la fusion — ce n'est que le début du déploiement. Avec CI/CD (Intégration Continue / Déploiement Continu), tu automatises le processus de test et de déploiement dès que le code arrive sur main.

GitHub Actions est un choix populaire pour cela. Tu gères tes workflows directement depuis la CLI :

gh workflow view

Ceci vous donne un aperçu interactif des derniers jobs exécutés par workflow. Vous voyez directement si un déploiement a réussi ou où cela a échoué.

Un exemple simple de workflow GitHub Actions pour un projet PHP :

name: Deploy naar productie
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Synchroniseer naar server
        run: rsync -avz ./ gebruiker@server:/var/www/html/

Chaque push vers main déclenche maintenant automatiquement un déploiement. Plus de FTP manuel, plus de fichiers oubliés. Votre code passe en production directement, de manière reproductible et traçable.

Conseils Git pratiques pour un usage quotidien

• Commitez tôt, commitez souvent. Les petits commits ciblés sont plus faciles à relire et à annuler que de gros blocs de code.
• Utilisez git stash lorsque vous devez changer rapidement de branche sans committer un travail à moitié terminé : git stash push -m "WIP: formulaire de connexion".
• Consultez votre historique avec git log --oneline --graph pour une vue claire de vos branches et de vos commits.
• Utilisez des tags pour les versions : git tag -a v1.2.0 -m "Version de sortie 1.2.0" — vous savez ainsi toujours quel commit correspond à quelle version de production.
• Ne poussez jamais sur main sans revue — protégez votre branche principale via les règles de protection de branche sur GitHub ou GitLab.
• Rédigez un bon README et documentez vos conventions Git (nommage des branches, style des commits). Les nouveaux arrivants dans l’équipe vous en remercieront.

Conclusion : Git est la colonne vertébrale de votre processus de développement

De git init à un déploiement automatisé — Git est le tissu conjonctif du développement logiciel moderne. Il vous donne le contrôle sur votre codebase, rend la collaboration évolutive et vous permet de déployer en toute confiance.

Les points clés en résumé :

• Commencez chaque projet avec git init et un .gitignore réfléchi.
• Travaillez avec des branches — gardez main stable et déployable.
• Utilisez des pull requests ou des merge requests comme porte de qualité, même en solo.
• Automatisez votre déploiement avec l’intégration et le déploiement continus via GitHub Actions ou GitLab Pipelines.
• Rédigez des messages de commit significatifs — vous documentez votre propre travail.

Git n’est pas un outil que l’on « apprend une fois » et dont on a fini. C’est une compétence que vous affinez à chaque projet. Mais avec ces bases, vous êtes immédiatement plus productif, votre équipe collabore plus facilement, et vous dormez plus sereinement en sachant que chaque déploiement est traçable et réversible.