Git название ветки - чувствительно к регистру или нечувствительно к регистру?

Я новый пользователь git и недавно был обработан устаревшим репозиторием git, который нужно ухаживать.

Это исходное состояние (выводится через 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

Обратите внимание, что в данный момент существует ветвь с именем dev. Обратите внимание, что выделено несколько ссылок на dev (т.е. Dev, dev ^, dev ~ 2 и т.д.).

Для моей цели развития я пытался придумать ветку под названием "DEV, весь капитал".

Итак, я пошел дальше и создаю новую ветку (git ветвь DEV) и теперь запускаю 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

Обратите внимание, что оба dev и DEV перечислены как ветка. Отметим также, что на 5-й строке ссылки на dev теперь изменились на DEV (т.е. DEV, DEV ^, DEV ~ 2 и т.д.).

Каков выход 5-й строки? Я ожидаю, что он останется "dev" вместо того, чтобы быть замененным на "DEV", поскольку описания рядом с ним относятся к описанию старой работы во время ветвления "dev".

Я пытаюсь вернуться к тому, как это произошло, изменив имя ветки DEV на DV (работая git branch -m DEV DV) и показывая ветку, теперь выглядят так:

! [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

Обратите внимание, что ветвь теперь включает DV и dev. Также обратите внимание, что 5-я строка ссылок на dev теперь изменилась на DV (т.е. DV, DV ^, DV ~ 2 и т.д.).

Есть ли какой-нибудь способ вернуться к тому, как это было во время первоначального состояния с точки зрения ссылок на DV? Разве git запутался и переименовал мою историческую информацию с веткой, которая похожа и отличается только капиталом?

Помогите, как я могу это исправить. Спасибо кучи

Ответ 1

Итак, я пошел дальше и создал новую ветку (git branch DEV)

Вы создали новую ветку DEV когда были в ветке dev. Так что DEV и dev - это две ветки, которые указывают на один и тот же коммит. После того, как вы переименовали DEV в DV, теперь DV и dev - это две ветки, которые указывают на один и тот же коммит.

Все просто отлично. Если вы не хотите, чтобы DV беспокоил вас, вы можете просто запустить git branch -d DV чтобы удалить его. Если вы действительно хотите создать новую ветку, лучше придерживаться правила именования, которое не может сбить вас с толку и других.

Я никогда не использовал git show-branch. git log --oneline --all --graph --decorate=full рисует чистый лог-график.

Ответ 2

Отвечая только на вопрос в строке темы, не обращаясь к git show-branch (как ElpieKay, я никогда не использую git show-branch, кажется, информативное):

Git имена ветвей - и имена тегов, а также все другие ссылочные имена, поскольку их вызовы Git - изначально предназначались для чувствительности к регистру.

Все это отлично работает на машинах Linux/Unix, где код Git с учетом регистра чувствителен к регистру. Когда Git хранит имена веток в файловой системе в качестве имен файлов (что иногда бывает только), файловая система также чувствительна к регистру. ¹

Он иногда терпит неудачу в Windows и некоторых системах MacOS. В частности, он терпит неудачу, когда Git хранит ссылки в отдельных файлах, имена которых получены из имени ссылки, и эти имена файлов не учитывают регистр (например, сохраняют регистр, но складываются при совпадении имен или даже преобразуют все только в верхнем регистре, как в действительно старом формате FAT 8.3, но мы можем надеяться, что никакая современная файловая система не сделает этого).

Как отмечалось выше, Git не всегда сохраняет имена ссылок в качестве имен файлов. Фактически, на начальном клоне все имена находятся в одном файле с именем .git/packed-refs, ² поэтому в этот момент они чувствительны к регистру. Но они становятся "распакованными" со временем, ³ а затем на некоторых системах они становятся фальсифицированными.

Поскольку он иногда терпит неудачу в некоторых системах, обычно лучше избегать использования нескольких имен ссылок, которые отличаются только в случае.

¹ Конечно, на современных Unix/Linux-системах теперь вы можете получить доступ к файловым системам, сохраняющим регистр, но нечувствительным к регистру, и теперь Windows и MacOS могут не сообщать case-folding для некоторых файловых систем. (Но если вы измените настройки по умолчанию, ожидайте, что программное обеспечение, предназначенное для вашего окна, будет терпеть неудачу, потому что оно будет. Такие вещи, как Photoshop, пытаются использовать файлы с именем foo и foo и ожидают, что это относится к одному и тому же файлу! )

² Этот файл с упакованными ссылками существует довольно давно, но не навсегда, и очень ранние версии Git могут его не использовать. Внутри Git приобретает новый "подключаемый интерфейс имен ссылок", а в будущих версиях Git не может использоваться ни этот файл, ни отдельные файлы для каждой ссылки.

³ В общем, создание или обновление ссылки приводит к тому, что распакованный файл ссылки появляется. Запуск git pack-refs --all заменит распакованные ссылки на упакованные, восстановив полную чувствительность к регистру. Без --all, git pack-refs упаковывает уже упакованные ссылки, что в значительной степени бесполезно для работы (оно предназначалось для случая, который больше не используется).