> Le deuxième utilisateur, un collègue bien intentionné mais un peu
> novice, est arrivé après le début du projet. Il a cloné le repo, et
> apporté quelques modifications aux sources, puis il a commité *et* fait
> ui aussi un "git push origin master", mais malheureusement avec des
> modifications insuffisamment vérifiées. Il aurait mieux valu ne lui
> donner qu'un accès en lecture seule, mais maintenant, c'est trop tard,
> la bêtise est faite.
Pour repartir sur des bases plus sécurisées, il serait préférable que
votre équipe adopte une méthode de travail de type "Fork and pull
request workflow". C'est la méthode utilisée par les services
d'hébergement Git (GitHub, Gitlab,...). Le dépôt principal appelé
"upstream" est récupérable par n'importe qui avec un fork/pull. Par
contre, le push est contrôlé par le mainteneur du dépôt initial qui
joue le rôle de "douanier" avant d'autoriser la publication des
nouvelles contributions. Cà nécessite plus de travail pour le
mainteneur/douanier mais çà parait incontournable si les contributeurs
sont débutants ou inconnus.
> Attention : si le dépôt est public, n'importe qui peut être en train de
> travailler sur la base de l'historique actuel, et il ne va pas être
> content si tu fais un force-push. Il est en général très mal vu de
> réécrire une histoire qui a déjà été rendue publique.
Si ce conseil pertinent d'Edgar ne suffit pas à convaincre, Linus
TORVALDS peut en rajouter une couche (en anglais) :
https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
Le ven. 24 janv. 2020 à 07:46, Marc TERRIER <marc.terrier@???> a écrit :
>
> Bonjour la Guilde,
>
> Soit un repo Git "de référence", créé initialement vide ("bare"), et qui
> a été cloné par deux utilisateurs, et qui se retrouve donc être le
> "remote" de leurs copies individuelles.
>
> Le premier utilisateur, c'est moi. Je suis l'initiateur du projet, je
> commite régulièrement, et je fais des "git push origin master" de temps
> à autre. Jusque là, tout va bien.
>
> Le deuxième utilisateur, un collègue bien intentionné mais un peu
> novice, est arrivé après le début du projet. Il a cloné le repo, et
> apporté quelques modifications aux sources, puis il a commité *et* fait
> lui aussi un "git push origin master", mais malheureusement avec des
> modifications insuffisamment vérifiées. Il aurait mieux valu ne lui
> donner qu'un accès en lecture seule, mais maintenant, c'est trop tard,
> la bêtise est faite.
>
> Après cela, moi, je pouvais toujours commiter dans mon coin, mais je ne
> pouvais plus "pusher" sur "origin master" sans avoir "pullé" auparavant
> et récupéré les modifications malheureuses du collègue, résolu les
> conflits manuellement, puis commité à nouveau. Maintenant, l'historique
> du projet est "crade", avec les quatre derniers commits qui ne sont que
> des commits de "régularisation".
>
> Il ne m'a pas été difficile de revenir à un historique plus "clean",
> dans mon repo local, en faisant "git reset <sha1 du dernier commit
> correct>", mais je ne peux toujours pas "pusher" sur "origin master"
> parce que ça me dit :
>
> $ git push origin master
> Enter passphrase for key '/home/marc/.ssh/id_rsa':
> To 192.168.1.139:nom_du_projet.git
> ! [rejected] master -> master (non-fast-forward)
> error: impossible de pousser des références vers
> 'git@192.168.1.139:nom_du_projet.git'
> astuce: Les mises à jour ont été rejetées car la pointe de la branche
> courante est derrière
> astuce: son homologue distant. Intégrez les changements distants (par
> exemple 'git pull ...')
> astuce: avant de pousser à nouveau.
> astuce: Voir la 'Note à propos des avances rapides' dans 'git push
> --help' pour plus d'information.
>
> Comment est-ce que je pourrais revenir en arrière ?
> Est-ce même possible ?
>
> Merci d'avance de vos suggestions,
>
> --
> Marc TERRIER
>
