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 :

Pourquoi les REBASE entraînent des conflits en série


Sujet :

GIT

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    Février 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 187
    Points : 65
    Points
    65
    Par défaut Pourquoi les REBASE entraînent des conflits en série
    BOnjour

    Je cherche une réponse à ma question et je n'arrive pas à la trouver sur le net. Je suppose que c'est dû à mon manque de culture sur GIT mais j'aurais voulu avoir votre avis.

    De ce que j'ai compris, un rebase permet de prendre tous les commits d'une branche et de les ajouter en tête d'une autre. Là où je n'arrive pas à comprendre c'est :

    -pourquoi y a-t-il des conflits à chaque fois que j'en fais ?
    -pourquoi ce sont les mêmes fichiers qui revienne. Pour certains rebase, j'ai eu à régler les conflits 10 voir 15 fois
    -Est ce qu'il y a un moyen d'éviter cela ?

    Merci

  2. #2
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    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 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Hello,

    Citation Envoyé par amira Voir le message
    De ce que j'ai compris, un rebase permet de prendre tous les commits d'une branche et de les ajouter en tête d'une autre.
    En effet. C'est bien l'esprit de la chose mais en réalité, tu peux rebaser un morceau de branche à peu près n'importe où.
    Ce qu'il faut garder à l'esprit, en revanche, c'est que cela ne va pas se faire comme si l'on débranchait une liste chaînée pour la ré-accrocher ailleurs. Comme les commits sont immuables par nature (parce qu'ils sont signés par leur somme SHA1 et qu'ils font chacun référence à leur commit parent), Git va en fait « rejouer » tes commits, c'est-à-dire appliquer chaque changeset au sommet de la branche comme s'il s'agissait d'un nouveau commit, mais apportant les mêmes changements.

    Là où je n'arrive pas à comprendre c'est :
    -pourquoi y a-t-il des conflits à chaque fois que j'en fais ?
    Justement parce que l'état du dépôt à l'endroit où tu rebases ta branche a changé entretemps. Si par exemple, tu fais un commit qui change un numéro de version de « 10 » vers « 11 » et qu'à l'endroit où tu rebases ta branche, on en est déjà à « 12 », alors Git te dira que l'état de la ligne concernée a déjà changé et qu'il faudra que tu choisisses entre ce nouvel état et celui que ton commit apporte.

    -pourquoi ce sont les mêmes fichiers qui revienne. Pour certains rebase, j'ai eu à régler les conflits 10 voir 15 fois
    Impossible de te donner une réponse précise sans connaître ces fichiers. Quelles sont les résolutions que tu as eu à mener en particulier ?

    -Est ce qu'il y a un moyen d'éviter cela ?
    Oui et non : les résolutions à mener lors d'une rebase sont grosso-modo les mêmes que celles d'un merge. Si le projet est mené proprement, il n'y en aura pratiquement aucune. Si elles apparaissent quand même, c'est qu'il y a une raison à cela.

    Il existe git rerere, pour « REuse REcorded REsolutions », lorsque l'on sait que celles-ci seront inévitables, qu'elles sont récurrentes, et surtout parfaitement identifiées.

    À part cela, les bonnes pratiques consistent surtout à :

    • Échanger avec les collaborateurs et s'arranger autant que possible pour travailler sur des modules distincts. C'était encore plus vrai avec les anciens SCM qui étaient moins efficaces ;
    • Ne pas laisser une branche évoluer trop longtemps sans la fusionner (sinon elle diverge trop) ;
    • Mettre fréquement à jour la branche principale (git pull) et au besoin, importer à intervalles réguliers son état dans la branche secondaire (avec git merge donc, mais depuis la branche secondaire et pas la branche principale). C'est souvent plus facile de le faire dans ce sens-là que dans l'autre à la fin de l'opération).


    À tout moment tu peux également comparer l'état de tes deux positions avec git diff <branche1> <branche2>, où <branche1> et <branche2> sont le nom de tes branches, bien sûr, mais peuvent en réalité être deux commits arbitraires, quels qu'ils soient et où qu'ils soient. C'est une bonne chose de le faire avant d'attendre la fin pour voir à l'avance si on diverge trop.

    Bon courage !

  3. #3
    Membre du Club
    Profil pro
    Inscrit en
    Février 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 187
    Points : 65
    Points
    65
    Par défaut
    Bonjour et merci pour ta réponse.
    J'ai effectivement fait des recherches et tu as raisons sur tous les points. Je voudrais compléter pour ceux qui tomberont sur ce points quelques notions que j'ai apprises en faisant mes recherches. Tout d'abord dans la manière de faire un rebase, une bonne vidéo est celle-ci :



    Ensuite une notion que je ne maîtrisais pas (et qui me faisait apparaître constamment des lignes "merge" sur mon historique) c'est qu'un rebase efficace doit être en mode force, ce qui est contre-intuitif. Pour éviter les soucis, le mieux reste le --force-with-lease

    https://blog.stack-labs.com/code/git_force_with_lease/

Discussions similaires

  1. Réponses: 4
    Dernier message: 18/04/2011, 11h39
  2. Réponses: 22
    Dernier message: 29/12/2010, 10h44
  3. Réponses: 2
    Dernier message: 19/07/2006, 18h37
  4. Réponses: 2
    Dernier message: 23/06/2006, 11h23

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