En tant que SCM distribué, git fait la distinction entre les concepts «faire un instantané de la copie de travail» (commit) et «référentiels de synchronisation» (push / pull / fetch).
Si vous n'avez qu'un seul clone local de votre référentiel, il n'est pas logique de pousser. Cependant, avec github, vous faire un autre clone (celui sur github), et en poussant vos changements a au moins un avantage: la sauvegarde. Si votre ordinateur meurt, vous avez toujours tout poussé jusqu'à présent sur github.
Bien sûr, ce n'est pas le but principal de github; github est destiné au partage de code, donc si votre projet est sur github, vous pouvez autoriser d'autres personnes à tirer de là, cloner votre projet, agir sur les demandes d'extraction de leurs clones, ou même donner à d'autres personnes de confiance un accès push à votre référentiel.
Une autre raison de pousser est si vous utilisez plusieurs clones locaux. Cela peut être utile pour diverses choses: par exemple, vous pouvez vouloir travailler sur deux branches différentes en même temps, ou vous pouvez essayer des opérations potentiellement destructrices sur votre référentiel; si tout fonctionne comme prévu, vous conservez le clone modifié (ou repoussez vos modifications dans le référentiel d'origine), mais si les choses vont au sud, vous pouvez simplement supprimer le clone foiré et revenir à l'original (qui est toujours inchangé) .
Certaines personnes utilisent même git pour le déploiement: la version de production est également un dépôt git, et la mise à jour vers une version plus récente est une question de récupération et d'extraction (évidemment, cela ne fonctionne que si vous n'avez pas besoin d'une étape de construction). Je ne le recommanderais pas nécessairement pour les choses sérieuses, mais pour les petites choses, c'est une solution simple et pragmatique.