IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

GIT Discussion :

git rebase help


Sujet :

GIT

  1. #1
    Membre chevronné

    Homme Profil pro
    développeur
    Inscrit en
    octobre 2013
    Messages
    1 512
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : développeur

    Informations forums :
    Inscription : octobre 2013
    Messages : 1 512
    Points : 1 933
    Points
    1 933
    Par défaut git rebase help
    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

  2. #2
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    septembre 2007
    Messages
    7 256
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 7 256
    Points : 23 259
    Points
    23 259
    Par défaut
    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.

  3. #3
    Membre chevronné

    Homme Profil pro
    développeur
    Inscrit en
    octobre 2013
    Messages
    1 512
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : développeur

    Informations forums :
    Inscription : octobre 2013
    Messages : 1 512
    Points : 1 933
    Points
    1 933
    Par défaut
    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.

  4. #4
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    septembre 2007
    Messages
    7 256
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 7 256
    Points : 23 259
    Points
    23 259
    Par défaut
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Git merge ou rebase
    Par Seth77 dans le forum GIT
    Réponses: 1
    Dernier message: 21/07/2020, 09h46
  2. Git rebase et push
    Par Amnael dans le forum GIT
    Réponses: 1
    Dernier message: 10/07/2018, 10h03
  3. VS Code et git rebase
    Par grunk dans le forum Visual Studio
    Réponses: 0
    Dernier message: 10/11/2017, 16h12
  4. W7 - GIT et les commandes dos - Please HELP!
    Par gazadonf77 dans le forum Windows
    Réponses: 2
    Dernier message: 05/10/2017, 18h06
  5. Explication git rebase
    Par ikane dans le forum ALM
    Réponses: 5
    Dernier message: 01/12/2016, 15h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo