web-dev-qa-db-fra.com

Nom de la branche Git - sensible à la casse ou insensible?

Je suis un nouvel utilisateur de git et j'ai récemment reçu un référentiel git obsolète à gérer.

C'est l'état d'origine (sortie par git show-branch):

! [cr232] CR 232 Release
        * [dev] Style Changes
---------------
        *   [dev] Style Changes
        *   [dev^] SMS 5.4
        *   [dev~2] Logo Change
        *   [dev~3] SMS 5.3
        *   [dev~4] SMS 5.2
        *   [dev~5] SIT R-0.3.3 EDW SMS Layers
        *   [dev~6] SIT Release R 0.3.0
       +*   [cr232] CR 232 Release
       +*   [cr232^] Dashboard Fix
       +*   [cr232~2] Release for system testing

Notez qu'il existe une branche appelée "dev" à ce stade. Notez que surligné, il y a plusieurs références à dev (c'est-à-dire dev, dev ^, dev ~ 2 etc.).

À des fins de développement, j’essayais de créer une branche appelée "DEV", toute capitale.

J'ai donc continué et créé une nouvelle branche (git branch DEV) et maintenant j'exécute git show-branch –date-order:

! [DEV] Style Changes
    ! [cr232] CR 232 Release
        * [dev] Style Changes
---------------
        *   [DEV] Style Changes
        *   [DEV^] SMS 5.4
        *   [DEV~2] Logo Change
        *   [DEV~3] SMS 5.3
        *   [DEV~4] SMS 5.2
        *   [DEV~5] SIT R-0.3.3 EDW SMS Layers
        *   [DEV~6] SIT Release R 0.3.0
       +*   [cr232] CR 232 Release
       +*   [cr232^] Dashboard Fix
       +*   [cr232~2] Release for system testing

Notez que dev et DEV sont répertoriés en tant que branche. Notez également que sur la 5ème ligne, les références à dev sont désormais devenues DEV (c'est-à-dire DEV, DEV ^, DEV ~ 2, etc.).

À quoi se réfère la sortie de la 5ème ligne? Je m'attendrais à ce qu'il reste "dev" au lieu d'être changé en "DEV" car les descriptions à côté se réfèrent à la description de l'ancien travail pendant la branche "dev".

J'essaie de revenir à la situation en modifiant le nom de la branche DEV en DV (en exécutant git branch –m DEV DV) et en montrant la branche maintenant:

! [DV] Style Changes
    ! [cr232] CR 232 Release
        * [dev] Style Changes
---------------
        *   [DV] Style Changes
        *   [DV^] SMS 5.4
        *   [DV~2] Logo Change
        *   [DV~3] SMS 5.3
        *   [DV~4] SMS 5.2
        *   [DV~5] SIT R-0.3.3 EDW SMS Layers
        *   [DV~6] SIT Release R 0.3.0
       +*   [cr232] CR 232 Release
       +*   [cr232^] Dashboard Fix
       +*   [cr232~2] Release for system testing

Notez que la branche inclut désormais DV et dev. Notez également que les références de la 5ème ligne à dev sont maintenant devenues DV (c'est-à-dire DV, DV ^, DV ~ 2, etc.).

Existe-t-il un moyen de revenir à ce qu'il était lors de l'état d'origine en termes de références DV? Le git s'est-il confondu et a renommé mes informations historiques avec une branche qui est similaire et ne diffère que par les majuscules?

Veuillez nous aider à résoudre ce problème. Merci des tas

gitgithubversion-controlgit-branch
17
jak

J'ai donc commencé et créé une nouvelle branche (git branch DEV)

Vous avez créé une nouvelle branche DEV lorsque vous étiez sur la branche dev. Donc DEV et dev sont deux branches qui pointent vers le même commit. Après avoir renommé DEV en DV, maintenant DV et dev sont deux branches qui pointent vers le même commit.

Tout va bien. Si vous ne voulez pas que DV vous dérange, vous pouvez simplement exécuter git branch -d DV pour le supprimer. Si vous voulez en effet créer une nouvelle branche, mieux vaut suivre une règle de dénomination qui ne peut pas vous confondre, vous et les autres.

Je n'ai jamais utilisé git show-branch. git log --oneline --all --graph --decorate=full trace un graphique de journal clair.

10
ElpieKay

Répondre à la question dans la ligne d'objet, sans rien aborder sur git show-branch ( comme ElpieKay , je n'utilise jamais réellement git show-branch; cela semble principalement informatif):

Les noms de branche Git - et les noms de balises, et tous les autres noms de référence , comme Git les appelle - étaient à l'origine destinés pour être sensible à la casse.

Tout cela fonctionne parfaitement sur les machines Linux/Unix, où le code de Git est sensible à la casse pour commencer. Lorsque Git stocke les noms de branche dans le système de fichiers en tant que noms de fichiers (ce qu'il ne fait que parfois ), le système de fichiers est également sensible à la casse.1

Il échoue parfois sous Windows et certains systèmes MacOS. Plus précisément, il échoue lorsque Git stocke des références dans des fichiers individuels, dont les noms sont dérivés du nom de référence, et ces noms de fichiers ne respectent pas la casse (par exemple, la préservation de la casse, mais la casse lors de la correspondance de noms; ou même tout convertir en majuscules -seulement, comme dans le très ancien format FAT 8.3, mais nous pouvons espérer qu'aucun système de fichiers moderne ne le fera).

Comme indiqué ci-dessus, Git ne stocke pas toujours les noms de référence en tant que noms de fichiers. En fait, sur le clone initial, tous les noms sont dans un seul fichier appelé .git/packed-refs,2 à ce stade, ils sont sensibles à la casse. Mais ils deviennent "déballés" au fil du temps,3 puis sur certains systèmes, ils deviennent pliables.

Parce qu'il échoue parfois sur certains systèmes, il est généralement préférable d'éviter d'utiliser plusieurs noms de référence qui ne diffèrent qu'en cas.

1Bien sûr, sur les systèmes Unix/Linux modernes, vous pouvez désormais accéder à des systèmes de fichiers respectant la casse mais ne respectant pas la casse, et Windows et MacOS peuvent désormais être informés de ne pas faire de casse pour certains systèmes de fichiers. (Mais si vous modifiez les valeurs par défaut, attendez-vous à ce que le logiciel destiné à votre boîtier échoue, car il le fera. Des choses comme Photoshop essaient en interne d'utiliser des fichiers nommés foo et FOO et attendez-vous à ce que cela se produise. se référer au même fichier!)

2Ce fichier de références compressées existe depuis un certain temps, mais pas pour toujours, et les premières versions de Git peuvent ne pas l'utiliser. En interne, Git est en train d'acquérir une nouvelle "interface de nom de référence enfichable" et les futures versions de Git pourraient n'utiliser ni ce fichier, ni des fichiers individuels par référence.

3En général, la création ou la mise à jour d'une référence entraîne la création d'un fichier de référence décompressé. Fonctionnement git pack-refs --all remplacera les références non empaquetées par des empaquetages, rétablissant la pleine sensibilité à la casse. Sans pour autant --all, git pack-refs ne contient que des références déjà emballées, ce qui est en grande partie un mode de fonctionnement inutile (il était destiné à un cas qui n'est plus utilisé).

38
torek