Discussion :

[kevin254kl]

Bonjour à tous,

J'ai pris l'habitude d'utiliser git merge très rapide, du coup je ne suis pas pro avec git rebase ou j'ai souvent des soucis.
Exemple j'étais sur un projet symfony, je fais un git rebase d'une autre branche. Après la gestion des conflits je fais un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git push --force maBranche

J'ai un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

error: failed to push some refs to

j'ai cru comprendre que c'est un problème de permission?
Auriez-vous un tuto à me conseiller sur developpez pour bien maitriser git rebase? Car à chaque fois j'ai des soucis à cause de méconnaissance

Merci

[Obsidian]

Bonjour,

La syntaxe de git push (hors options) est : git push [ dépôt [ refspec ] ], c'est-à-dire que le premier argument après la commande « push » est le nom du dépôt distant (généralement « origin » s'il n'y en a qu'un), suivi éventuellement d'un nom de branche, de tag ou de tout identifiant permettant de référencer un commit (à partir duquel on remonte tout l'historique, jusqu'à retrouver ce que l'on connaît éventuellement déjà). Si ce deuxième paramètre est omis, git considère que c'est soit la branche courante (qui sera mise à jour des deux côtés) si on est dessus, soit la position de HEAD si on est dans l'état détaché.

Donc, si tu as lancé git push --force maBranche, tu as essayé de pousser la branche courante vers un dépôt distant nommé « maBranche ». Ce dépôt n'existant probablement pas, tu as dû obtenir une erreur.

Si toutefois tu es sûr de bien avoir poussé la bonne branche vers le bon dépôt, alors il arrive fréquemment que le push -f soit interdit par les administrateurs des dépôts collaboratifs, ceci justement pour empêcher un collaborateur d'écraser les soumissions de ses collègues en pensant ne ré-écrire que son propre historique. C'est pourquoi on recourt souvent, quand c'est possible, à un système de pull request. Chaque collaborateur prépare sa propre branche et quand il l'estime prête, il soumet une requête pour que ce soit le mainteneur de la branche principale qui aille la chercher et l'intègre à la branche principale à l'aide d'un merge.

Dans ce cas de figure, si tu as fait un push -f vers une branche collaborative, il est possible que le refus vienne de là.

Dans tous les cas, il faut éviter de recourir quand on le peut à --force et --hard si on n'est pas à l'aise avec le fonctionnement exact de la chose. Malheureusement, ce sont pourtant les options les plus utilisées des débutants.

Quels sont les commandes exactes que tu as saisies jusqu'ici ?

Bon courage.

[kevin254kl]

Merci beaucoup pour ta réponse.
Après avoir regardé l'historique en effet j'ai spécifié origine, mais je crois aussi avoir essayé sans et j'avais aussi une erreur ref
J'ai finalement juste merge.
Du coup la bonne pratique avec rebase serait de pousser sur la branch local puis de push à la fin de la résolution des conflits?

Merci.

[Obsidian]

En fait, git rebase sert à re-baser une branche, c'est-à-dire à la « débrancher » de la branche dont elle est initialement partie et la reconnecter ailleurs. Généralement, il s'agit de le faire un peu plus en aval sur cette même branche originale, lorsque le travail a un peu trop évolué en parallèle et qu'il faut se resynchroniser avec l'état courant du projet. Par exemple, ici, on rebase la branche de droite, de A vers D :

                                         O z'
                                         |
                                         O y'
                                         |
                                         O x'
                                        /
        E O   O z                  E O /
          |   |                      |/
        D O   O y                  D O
          |   |                      |
        C O   O x     → vers →     C O
          |  /                       |
        B O /                      B O
          |/                         |
        A O                        A O

Pour ce faire, git « rejoue » les commits « x », « y », et « z », c'est-à-dire qu'il réapplique leurs différentiels respectifs à partir de D comme s'il s'agissait de nouvelles modifications. Et une fois que c'est fait, il déplace simplement l'étiquette de la branche sur le dernier commit.

En ce sens, « rebase » n'est pas à strictement parler l'équivalent d'un merge. Il s'agit simplement de déplacer la branche pour pouvoir continuer à travailler dessus. Évidemment, si la branche originale a trop divergé, les mêmes problèmes qu'avec une fusion (merge) se posent : des conflits. Et ils se résolvent de la même façon.

Si tu pousses ensuite ta branche de travail vers le serveur et que tu l'avais déjà fait au moins une fois auparavant, le serveur ne sait pas qu'elle a été déplacée. Donc, il ne comprend pas le cheminement suivi et c'est là que le « --force » s'impose. Cela signifie « contente-toi de la déplacer à l'endroit actuel et ne te soucie pas de l'historique ». C'est normal dans ce cas de figure, mais on comprend que cela ne doit pas être utilisé sur une branche collaborative : uniquement sur ses branches personnelles.

Une manière propre de le faire si jamais le serveur ne t'autorise pas du tout à le faire consiste à déclarer une nouvelle branche à cet endroit, à pousser cette nouvelle branche, et à supprimer l'ancienne.

Si tu utilises git merge par contre, tu re-fusionnes ta branche avec la branche principale avant de continuer à travailler. À ce moment-là, les deux branches continuent à co-exister mais vont se retrouver temporairement à un endroit commun (le commit G).

        G O ← Merge
          |\
        F O \
          |  \
        E O   O z
          |   |
        D O   O y
          |   |
        C O   O x
          |  /
        B O /
          |/
        A O

Ou alors, tu intègres ponctuellement les changements de la branche principale dans la tienne. Les deux branches continuent d'être distinctes et tu ne pollues pas la branche principale :

        G O
          |
        F O   O ← Merge
          |  /|
        E O / O z
          |/  |
        D O   O y
          |   |
        C O   O x
          |  /
        B O /
          |/
        A O

Dans les deux derniers cas, l'avantage est que tu préserves l'historique. Le serveur est donc au courant du cheminement et te laisse faire. L'inconvénient est que justement, cela introduit un point de fusion officiel visible dans l'historique ensuite, ce qui n'est pas forcément souhaitable. En outre, cela rend plus difficile un éventuel rebase ultérieur.

Du coup la bonne pratique avec rebase serait de pousser sur la branch local puis de push à la fin de la résolution des conflits?

Pas forcément. Il nous faudrait déjà le message d'erreur complet. Ce que tu nous présentes n'est pas suffisant pour conclure. Normalement, si tu as résolu les conflits en local juste après le rebase, tu ne devrais pas avoir de difficulté à pousser le tout ensuite. Il faudrait voir si tu as fait des erreurs pendant le rebasage ou si c'est le serveur qui te l'empêche.