Pousser — ce que c’est, comment fonctionne git push et quand le faire

Qu’est-ce qu’un push dans Git

Git push est une commande qui transfère les commits d’un dépôt local vers un dépôt distant. Contrairement à un commit, qui enregistre les modifications uniquement sur la machine locale du développeur, un push publie ces modifications pour toute l’équipe. Push est une étape obligatoire avant la création d’une Pull Request et le déploiement.

L’architecture de Git suppose que chaque développeur travaille dans son propre dépôt local. Les commits sont créés localement et s’accumulent jusqu’à ce que le développeur décide de les pousser. Cela offre une liberté : vous pouvez faire de nombreux commits locaux, expérimenter et réécrire l’historique sans affecter les collègues.

# Pousser vers le remote origin, branche main
git push origin main

# Pousser la branche actuelle vers le remote avec upstream
git push -u origin feature/new-dashboard

# Pousser toutes les branches avec des noms correspondants
git push --all origin

# Force push avec lease (push forcé sécurisé)
git push --force-with-lease

Après un push, le dépôt distant met à jour les refs (références de branches) pour qu’elles pointent vers les nouveaux commits. Les autres développeurs peuvent récupérer ces modifications via git pull ou git fetch. Cet échange de commits constitue la base du développement collaboratif.

Comment fonctionne git push

La commande git push compare les branches locales et distantes et ne transfère que les commits manquants. Git ne renvoie pas tous les fichiers — il ne transfère que le delta, ce qui rend le push rapide même pour les grands dépôts. Protocole Git utilise le transfert intelligent, qui minimise la quantité de données transmises.

Si la branche distante contient des commits qui ne sont pas présents localement, le push sera rejeté. C’est un mécanisme de protection qui évite la perte de modifications. Dans cette situation, le développeur doit d’abord exécuter git pull, fusionner les modifications, puis pousser à nouveau. Une alternative est le force push, qui écrase la branche distante, mais il doit être utilisé avec précaution.

Comprendre les dépôts distants est la clé pour bien pousser. Généralement, origin est le nom du dépôt distant par défaut. La commande git remote -v affiche la liste des dépôts distants et leurs URL. Vous pouvez ajouter plusieurs remotes (par exemple, origin pour le dépôt principal et upstream pour un fork).

Quand pousser des modifications

La règle principale : poussez après chaque étape de travail logiquement terminée. Si un développeur a terminé une tâche ou une partie de celle-ci — il est temps de pousser. Cependant, pousser du travail inachevé qui casse la compilation n’est pas recommandé. Compilation non cassée est l’exigence minimale pour pousser vers n’importe quelle branche.

Dans le développement en équipe, le rythme suivant est adopté : le matin — git pull pour obtenir les modifications des collègues, pendant la journée — plusieurs commits et un ou deux pushes, le soir — un push final de toutes les tâches terminées. Plus un développeur pousse fréquemment, plus le risque de conflits de fusion est faible et plus l’avancement du travail est transparent.

• Après avoir terminé une tâche — commiter et pousser la solution finale dans la branche de fonctionnalité
• Avant de partir — pousser le travail inachevé dans une branche de fonctionnalité (pas dans main !)
• Avant de créer un PR — s’assurer que tous les commits sont poussés et disponibles pour la relecture
• Après rebase — pousser avec --force-with-lease dans votre branche de fonctionnalité

Règles de push sécurisé

Le push sécurisé est un ensemble de règles qui empêchent la perte de données et les conflits dans l’équipe. La première et la plus importante règle : ne jamais pousser directement dans la branche main ou master si le projet n’a pas de déploiement direct configuré. Dans les équipes modernes, la protection de la branche main est configurée au niveau de la protection de branche GitHub.

La deuxième règle : synchronisez-vous avec la branche distante avant de pousser. Exécutez git pull --rebase pour éviter les commits de fusion lors de la fusion. Cela simplifie l’historique et le rend linéaire. Si un push est rejeté — n’utilisez pas un simple force push, mais d’abord découvrez quels commits sont apparus sur la branche distante.

La troisième règle : configurez des hooks pre-push qui exécutent automatiquement les tests et les linters avant l’envoi. Si les tests échouent — le push est bloqué. Ces hooks sont configurés via Husky ou les hooks Git (fichier pre-push dans .git/hooks).

La quatrième règle : ne poussez pas de gros fichiers binaires. Git n’est pas conçu pour stocker des artefacts binaires — ils gonflent le dépôt et ralentissent les opérations. Pour les gros fichiers, utilisez Git LFS (Large File Storage). Si un binaire a déjà été poussé et se trouve dans l’historique, il doit être supprimé via git filter-branch.

Que faire si le push échoue

La cause la plus courante d’un échec de push est que la branche distante contient des commits qui ne sont pas présents localement. Cela se produit lorsqu’un autre développeur a poussé ses modifications dans la même branche. Solution : exécutez git pull, résolvez les éventuels conflits et poussez à nouveau.

# Push rejeté — d’abord fetch et rebase
git fetch origin
git rebase origin/main
# Résoudre les conflits, puis :
git push --force-with-lease

# Ou simplement fusionner les modifications distantes
git pull origin main
git push

La deuxième raison — absence de permissions d’écriture sur la branche. Si la branche main est protégée par des règles de protection de branche, les pushes directs sont interdits. Solution : pousser vers une branche de fonctionnalité et créer une Pull Request. Les paramètres de protection sont généralement administrés via les paramètres GitHub ou les branches protégées de GitLab.

La troisième raison — problèmes d’authentification. Identifiants obsolètes, passage à SSH ou modification du jeton d’accès personnel. Solution : vérifiez l’URL distante (git remote -v) et mettez à jour les identifiants. Depuis 2021, GitHub a supprimé l’authentification par mot de passe pour HTTPS — utilisez un jeton personnel ou une clé SSH.