Push rejeté

Bonjour,

Souhaitant me remettre à utiliser Git, je l'ai installé et configuré. Tout fonctionne bien, les commits sans problème, j'ai bien lié mon répo Github à mon local avec git remote add origin https://github.com/boopr/Javaquarium.git mais pourtant au moment de push j'ai cette erreur :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Username for 'https://github.com': boopr
Password for 'https://boopr@github.com': 
To https://github.com/boopr/Javaquarium.git
 ! [rejected]        master -> master (fetch first)
error: impossible de pousser des références vers 'https://github.com/boopr/Javaquarium.git'
astuce: Les mises à jour ont été rejetées car la branche distante contient du travail que
astuce: vous n'avez pas en local. Ceci est généralement causé par un autre dépôt poussé
astuce: vers la même référence. Vous pourriez intégrer d'abord les changements distants
astuce: (par exemple 'git pull ...') avant de pousser à nouveau.
astuce: Voir la 'Note à propos des avances rapides' dans 'git push --help' pour plus d'information.

Savez-vous pourquoi ? Car mon répo github est vide !
Merci de votre aide

Il n'est pas vide car il y a deux commits dessus ! Mais tu peux forcer le push avec l'option -f, par exemple : git push -f origin.

Ne jamais utiliser git push -f. Jamais.

Même lors d'un rebase (pour squash des commits par exemple) ?

Surtout ici. Le proposer en premiere solution a ce sujet est criminel.

Bah vu qu'il y a un commit qui créer un README et un autre qui le supprime, je trouve plus propre de ne rien avoir du tout. Mais j'aurais dû plus expliquer la dangerosité de cette commande !

Ne jamais utiliser git push -f. Jamais.

Même lors d'un rebase (pour squash des commits par exemple) ?

Normalement non. La plupart des plateformes desactivent le force par defaut d'ailleurs.
Tu peux squash et rebaser autant que tu veux en local, pour avoir un joli historique avant de pusher. Les risques de problemes, d'inconsistance et d'effacement d'historique sont tellement important avec le push force que l'on prefere generalement utiliser un commit revert ou autre pour corriger a posterio une erreur pushee.

On est des criminels, alors sur ZdS

Désolé, j'avais commencé à écrire ma réponse mais un imprévu est arrivé.

En tout cas, merci de votre aide, j'ai bien résolu mon problème. Petite question quand même, Git ne s'utilise qu'avec Github où je peux conserver les fichiers du git sur mon ordinateur (ou un disque dur) et une application pour me gérer tout ça ? (Je préfère des applications locales que des sites internet…).

Encore merci.

Pour quelles raisons faites vous des push forcés ?

Parce qu'il est explicitement écrit dans nos règles de contributions :

… J'en déduit que c'est très mal

C'est effectivement refusé et même désactivé dans toute boite un peu sérieuse.
C'est pas parce que ZdS se l'autorise que ce n'est pas le mal absolu.

La différence c'est que les PR sont un outils Github qui vous utilisez pour un truc participatif. Les PR ne font pas partie de votre historique donc ça ne change rien à ce que j'évoque. Par ailleurs, le travail de squash et de mise au propre du travail à pusher se fait… avant de pusher. Il est donc de la responsabilité de la personne qui fait la PR de le faire avant. Sauf que comme ZdS utilise des PR et pas d'outil de relecture collaborative, tu es obligé de « pushé » puis de faire une PR.

Aurais-tu un exemple d'outil de la sorte ? Cela consisterait à faire revoir le code par d'autres avant de l'envoyer sur un autre dépôt que celui en local ?

En fait, le push -f est mal sur des dépôts utilisés par plusieurs personnes. Sur un dépôt (ou une branche d'un dépôt) utilisé(e) par une seule personne, ça ne pose pas de problème !

Je me permet de ré-itérer ma question :

Petite question quand même, Git ne s'utilise qu'avec Github ou je peux conserver les fichiers du git sur mon ordinateur (ou un disque dur) et une application pour me gérer tout ça ? (Je préfère des applications locales que des sites internet…).

Merci de votre aide!

Il y a pléthore d’outils.

Ensuite, c'est au workflow de définir la manière dont tu travailles, donc cela va également dépendre de la méthode Agile utilisée mais globalement, sur une tâche atomique cela peut se passer comme suit:

• Développement / Implémentation. De un à quelques commits selon la granularité de la tâche, référencé par l'identifiant de la tâche. Sur une branche ou non, selon le workflow git défini.
• Mise en review de l'ensemble des commits (avec les outils soient tu dois donner la plages des hashs des commits locaux, soit créer un patch à uploader).
• Correction des petits soucis du code via des commits à la con ("[id] typo - to rebase" par exemple) ou pas (si la relecture montre que le code est mauvais).
• Lorsque le code est validé, celui qui l'a proposée rebase, squash, de manière à obtenir un historique parfait.
• Il push.

Rien n'est sur le dépôt avant l'acceptation du code local. Après, c'est dans le cas où les gens travaillent dans une même organisation car il faut pouvoir donner les droits de mettre en ligne les propositions, etc. Les PR sont en fait l'outil collaboratif qui permet de concilier les deux:

• relecture de code
• historique propre

Et du coup, la partie qui consiste à demander de rebaser ou réarranger l'historique de la PR a pour seule différence avec le rebase local que le fait qu'elle soit techniquement déjà pushé sur un clone. Mais au final, le dépôt officiel lui, n'utilise jamais de force et aucun dépôt ne devrait, sauf ceux destiné à fait des PR.

Tu peux avoir des dépots git locaux juste pour avoir le côté "versionnement". Un simple git init dans un dossier et pouf ca y est tu as un dépot git qui fonctionne en local !

Merci, c'est vraiment ce côté historique qui m'intéresse sur Git, étant donné que je ne travail que sur des petits projets.

J’ai été confronté au même problème !!

Pour résoudre : git pull —rebase

git push -u origin main

La commande git push -u origin main ne fonctionnera pas comme prévu. À l’époque, l’OP travaillait bien sur la branche master et non pas main, comme on peut le voir dans son premier message.

À l’époque de l’ouverture du sujet, le nom par défaut donné à la branche par défaut par GitHub n’était pas main mais master.