Вам не нужно слишком беспокоиться о каплях внутри пустого хранилища. Что лучше понять, так это то, что каждый репозиторий состоит из объектов фиксации, которые содержат точную файловую структуру на момент фиксации в этом репозитории.
В вашем примере, пользователь A локально генерирует commitA, пользователь B локально генерирует commitB, оба они были основаны на master на голом репозитории, который бы указывал на объект commit (скажем) commitBase. Это означает, что у них обоих есть родительский элемент commitBase.
Когда A нажимает, он помещает свою commitA в пустой репозиторий, который перемещает указатель главной ветви вверх на commitA. Вся информация о файле1 находится внутри объекта коммита commitA (вместе с информацией об остальной структуре файла).
Прежде чем B отправит, он должен сначала внести изменения для commitA в свой репозиторий, потому что указатель удаленной главной ветки больше не указывает на commitBase. Он не может нажать, пока он не синхронизируется с удаленным на объектах фиксации и указателях ветвления. Таким образом, когда он получает объект commitA в свой репозиторий, он собирается получить fileA как часть этого, который появится в его файловой системе, если он выполнит извлечение или перебазирование, но получит только объект commit в свой репозиторий (не файл в его рабочий каталог), если он делает выборку. Fetch просто обновляет git с помощью новых объектов коммитов, не изменяя свой собственный указатель главной ветви. Именно в момент слияния / перебазирования git должен будет принять некоторые решения о файлах в рабочем каталоге, например, если обычные файлы легко объединяются, или новые файлы могут быть просто помещены на диск, или если они слишком большие. конфликт, и вам придется вручную разрешать конфликты в файлах.
В вашем простом примере у вас нет конфликта, поэтому вы должны либо перебазировать и сделать свой commitA ставшим commitA2 и иметь родителя для commitB, либо объединить и сохранить родительский объект вашего commitA как commitBase, но сгенерировать новый объект commitM, который будет результат слияния B и A.
То, как git внутренне представляет это в своей директории .git / objects в любом из 3 репозиториев, на данный момент не имеет значения. Возможно, он сжимает и перемещает содержимое, чтобы максимизировать базу данных всех этих объектов, как ему нравится, но это не то, о чем я когда-либо беспокоился, пытаясь понять, как работают объекты фиксации для файлов.