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 :

Publication de la FAQ Git


Sujet :

GIT

  1. #1
    Community Manager

    Inscrit en
    avril 2014
    Messages
    670
    Détails du profil
    Informations forums :
    Inscription : avril 2014
    Messages : 670
    Points : 9 509
    Points
    9 509
    Par défaut Publication de la FAQ Git
    Publication de la FAQ Git
    avec une sélection de cent-dix meilleures réponses à vos questions

    Chers membres du club,

    j'ai l'immense plaisir de vous annoncer la publication de la FAQ Git avec une sélection de cent-dix meilleures questions réponses pour apprendre l'outil de gestion de versions décentralisé Git.

    Ce nombre est appelé à évoluer avec vos différentes contributions.

    Nous remercions Marc Loupias pour son engagement à la rédaction de cette première vague de questions réponses. Nos reconnaissances également à Alexandre Laurent, Anthony Defranceschi et Mickael Baron, pour la relecture technique, à Jérôme Marsaguet et Djibril pour l'assistance technique à la mise en forme et Bruno Barthel pour les corrections orthographiques.

    Bonne lecture et n'hésitez pas à nous contacter, si vous souhaitez contribuer.
    Pour contacter les différents services du club (publications, partenariats, publicité, ...) : Contacts

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

    D'abord merci pour cet excellent et considérable travail. La rubrique Git en a bien besoin, car elle est toujours enterrée sous la « hiérarchie » historique des forums et reste peu visible.

    Par contre, désolé d'intervenir deux ans après la parution de de cette FAQ mais je tique sur la section consacrée à rebase : « Réécriture de l’historique (rebase) ».

    git rebase sert à « rebaser » une branche, c'est-à-dire en changer la base, soit encore : la décrocher de son emplacement courant pour la repositionner ailleurs. La plupart du temps, on s'en sert pour repositionner le travail d'une branche de développement qui a duré un peu trop longtemps vers l'état actuel du produit sur lequel on travaille et poursuivre tranquillement. Par contre, ça ne sert pas du tout à ré-écrire l'historique en soi, surtout qu'il n'est pas du tout recommandé de ré-écrire l'historique sans motif valable (ça l'est, bien sûr, pour préparer une branche propre avant de la soumettre pour intégration définitive).

    Il se trouve que rebase est très utile et que rebase -i l'est encore plus : c'est le genre de petite amélioration que l'on apporte à un concept existant et qui en révolutionne tellement l'usage que ça change l'approche de l'outil entier. Il y a beaucoup de gens qui utilisent — à raison — cette fonction pour « rebaser une branche au même endroit », ce qui est conceptuellement un non-sens mais qui est utile uniquement pour les effets de bord du mode interactif : pouvoir à la fois sélectionner les commits qui nous intéressent (dont faire du cherry-picking), en exclure d'autre et amender les dernier, le tout en une seule opération.

    Par contre, non seulement ce n'est pas l'objet de la chose et la ré-écriture n'est pas encouragée en dehors de ses propres branches privées, mais il y a des pièges à éviter lorsque l'on utilise rebase, en particulier si la branche concernée contient des merge points : si on le fait sans précaution, Git va essayer de retrouver tous les commits qu'il peut atteindre et les réappliquer linéairement, sur une seule branche, sans préserver la structure initiale ! Et comme cela va pratiquement toujours provoquer des conflits, l'utilisateur va se retrouver avec un dépôt sans dessus-dessous et une opération interrompue avant la fin.

    Il existe par ailleurs des commandes dédiées à ce genre d'opération, telles que filter-branch qui, elle, sert officiellement à ça :

    Code Shell : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    $ git --help -a
    …
       filter-branch        Réécrire les branches
    …

    C'est intéressant également car git rebase est très largement représenté dans les questions des utilisateurs, beaucoup plus que la normale attendue, au point qu'on se demande parfois où ils veulent en venir. Son utilisation pour ré-écrire l'historique est déjà une explication, le fait de le voir officiellement présenté comme servant à cette fin dans une FAQ confirme que la confusion est fréquente (et que donc, cela devrait justement devenir une entrée de FAQ également).

    On le trouve parfois utilisé, également, lorsque quelqu'un veut faire officiellement démarrer un nom de branche à un nouvel endroit déjà identifié. Au lieu de faire un branch --force ou un checkout -B, on a vu des solutions utilisant rebase, également. Et je pense que ceci est dû à des habitudes prises dans d'autres SCM qui gèrent les branches différemment et dans lesquels il n'est pas possible de s'en sortir autrement.

    Du coup, je serais bien intéressé d'avoir l'opinion de l'entourage à ce sujet en particulier. Pour l'instant, je poste ici pour faire remonter la discussion et la signaler aux personnes directement concernées mais au besoin, on déplacera le fil vers une discussion dédiée.

    Merci à tous.

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