Introduction

git push téléverse les commits locaux vers un remote et met à jour les branches et tags de ce remote. C'est ainsi que votre travail devient visible aux collaborateurs.

Push basique

git push                          # branche courante vers son upstream
git push origin main              # explicite
git push -u origin feature/login  # définit l'upstream et push

Le flag -u (ou --set-upstream) lie la branche locale à la distante de sorte que les futurs git push et git pull n'aient besoin d'aucun argument.

Pousser des tags

Les tags ne sont pas poussés par défaut :

git push origin v1.2.3
git push origin --tags          # tous les tags
git push --follow-tags          # tags atteignables depuis les commits poussés

--follow-tags est le défaut le plus sûr pour les workflows de release.

Supprimer des branches distantes

git push origin --delete feature/login
# équivalent
git push origin :feature/login

Force-pusher en sécurité

Réécrire l'historique (rebase, amend, squash) nécessite un push forcé. Préférez toujours --force-with-lease, qui refuse d'écraser les refs ayant bougé sur le serveur :

git push --force-with-lease
git push --force-with-lease=feature/login:abcd1234

Ne faites jamais --force aveuglément vers une branche partagée comme main.

Configurer les défauts de push

git config --global push.default simple    # défaut depuis 2.0
git config --global push.autoSetupRemote true   # 2.37+ : -u automatique

Avec push.autoSetupRemote activé, un simple git push sur une nouvelle branche crée la branche distante et les lie automatiquement.

Ce qui se passe pendant un push

1. Git local négocie avec le remote pour trouver les commits communs.
2. Il empaquette et téléverse seulement les objets manquants.
3. Le remote exécute les hooks pre-receive et update.
4. Si accepté, les refs sont mises à jour atomiquement.
5. Le hook post-receive s'exécute (CI, mirroring, etc.).

Pushes atomiques et signés

--atomic transforme les pushes multi-refs en une seule transaction ; soit chaque ref se met à jour, soit aucune, ce qui empêche les déploiements partiels. --signed envoie un certificat de push signé par GPG que certains hôtes journalisent pour audit :

git push --atomic origin main release/1.2
git push --signed origin main

Pour les systèmes automatisés, l'option --receive-pack vous permet de spécifier un receive-pack alternatif sur le serveur, occasionnellement nécessaire pour des hôtes avec des binaires non standard. Utilisez toujours git push --dry-run lors du scripting de pushes destructifs pour la première fois.

Erreurs fréquentes

Pousser vers main alors que vous vouliez une branche de feature, parce que vous avez oublié sur quelle branche vous étiez. Exécutez git status d'abord. Utiliser git push --force contre main et réécrire les commits des autres ; récupérez via le reflog du remote (si vous avez un accès shell) ou en repushant depuis le clone d'un coéquipier. Pousser sans identifiants configurés et rester bloqué sur une invite de mot de passe ; configurez un assistant d'identifiants ou une clé SSH. Enfin, les gros pushes peuvent échouer au dernier moment si un hook les rejette ; si c'est le cas, le message de rejet nomme le commit fautif. Lisez-le attentivement plutôt que de relancer aveuglément.