TL; DR: тут нечего делать. Все суперпроектные коммиты всегда направляют все на отдельные заголовки. -b s не используются ни при фиксации, ни при git add ing, только при git submodule update --remote ing, и даже тогда вы все еще находитесь на отдельном HEAD, просто на другом.
В Git подмодули - это просто отдельные репозитории Git. Фиксация суперпроекта всегда записывает один конкретный хеш, к которому будет принудительно применен каждый подмодуль. Так, например, если вы сделали коммит суперпроекта с хешем a123456, например, a123456 уже пинов каждого субмодуля суперпроекта: подмодуль sub/A фиксирован навсегда (для этого commit), скажем, на aaaaaaaa, а подмодуль moduleB фиксируется навсегда (для этого коммита) на bbbbbbb. Когда вы вернетесь к фиксации a123456 в суперпроекте и запустите git submodule update, sub/A будет отсоединен от sub/A aaaaaaaa, а moduleB отсоединен от bbbbbbb.
Чтобы отсоединить подмодули, вы должны cd sub/A; git checkout master и cd moduleB; git checkout master. Вы можете полуавтоматизировать это, используя git submodule update --remote, который использует записанную ветвь, но на самом деле это не переключение sub/A на (его) master, а, скорее, чтобы выяснить, что sub/A ' remote s origin/master по идентификатору хэша и переключите sub/A на этот коммит в качестве отдельного HEAD. Таким образом, sub/A будет продолжать работать в режиме HEAD.
Использование git add в суперпроекте просто берет текущий HEAD (обычно отсоединенный, но даже если нет, фактический хеш-идентификатор, сообщаемый git rev-parse) из каждого подмодуля и записывает его в индекс суперпроекта, так что один идентификатор хэша будет в следующем коммите суперпроекта. Название ветки в подмодуле здесь не очень важно. Единственное использование этих -b master s в git submodule add предназначено для git submodule update --remote, и даже в этом случае субмодуль не должен находиться в ветви , это просто для автоматического обновления detached-HEAD подмодуля .