... но я делаю что-либо незаконное с точки зрения Git?
Нет. Однако важно признать несколько вещей об этом слегка странном состоянии.
Git имеет только один репозиторий, и --git-dir говорит ему, где найти, что одно хранилище.
Git имеет только один рабочий дерево, и --work-tree говорит ему, где найти, что одна работа дерево (и отменяет настройку core.bare).
У Git есть только один номер HEAD (но см. Сноску 1), а --git-dir сообщает, где найти этот файл HEAD.
Git имеет только один индекс, и ... --git-dir говорит ему, где найти, что один индекс, если не переопределяется переменная окружения.
Именно эти последние биты, путешествие людей вверх, в основном при использовании post-receive сценариев для развертывания некоторых конкретных отраслей.
Если вы используете только одну ветвь в одном дереве, то один индекс не является проблемой. Если вы начинаете развертывание двух или более ветвей на двух рабочих деревьях, один из них становится проблемой.
Аналогичным образом, один файл HEAD обычно не является проблемой, особенно если вы развертываете только ветвь master, когда голый репозиторий был создан обычным способом, с master в качестве текущей ветви. (Голый репозиторий по-прежнему имеет текущую ветку, которая является той, что находится в ее файле HEAD.) Когда люди клонируют голый репозиторий, их клоны по умолчанию проверяют, какая ветка является текущей в голом репозитории, поэтому, если вы начнете развертывать несколько разных ветвей , люди могут удивляться тому, что их клоны начинаются в репозитории QA или test или develop или что-то еще, а не master.
(HEAD) Просто нужно, чтобы люди знали, что их ветка клонов по умолчанию может их удивить, и они должны проверить ветвь развития, если это то, что они хотят. Это единственный файл индекса, который вызывает настоящую проблему, поэтому см. Сноску 1.)
Если вы используете git worktree add, доступный в Git 2.5 и более поздних версий, это уже не так. Дополнительные рабочие деревья, конечно, предоставляют свое собственное дерево работы, но также предоставляют свои собственные HEAD, а также их собственный индекс.
Вы можете указать свой собственный индекс, используя переменную окружения GIT_INDEX_FILE, которая всегда переопределяет нормальные вычисления Git. Это также дает возможность сделать несколько развертываний филиалов: пусть одна ветка использует индекс по умолчанию и дает остальным собственный индексный файл (по одному каждому).
Использование нескольких рабочих столов и нового режима updateInstead для push.denyCurrentBranch может быть лучшим способом автоматизации развертывания, но я на самом деле не тестировал это.
В последних версиях Git были введены «разделенные индексы», в которых очень большие индексные файлы «разделены» на части, которые не сильно меняются, и те части, которые делают это, Гит быстрее. Разделение индекса немного волшебное (хотя в конечном счете оно явно детерминировано и предсказуемо) и знает, как обращаться с альтернативными файлами индекса, поэтому вам не нужно ничего об этом знать, но это делает «один индексный файл» требованием бит подозреваемого. В любом случае, добавленные рабочие строки от git worktree add по-прежнему получают собственный индексный файл (или пара индексов), поскольку это необходимо.