Спасибо за обновление вашего вопроса, теперь оно стало более понятным.
Я полагаю, что ваша проблема основана на неправильном понимании рабочего процесса Git;Git не приравнивает каталоги к ветвям, он приравнивает представление вашей файловой системы к ветвям.Это мощно - но легко выстрелить себе в ногу.Позвольте мне объяснить.
Git действует как файловая система отслеживания истории, поддерживаемая базой данных, с дифференциальной версией.Это «выше» вашей файловой системы, а не «часть» ее.Он не использует вашу файловую систему для представления ветвей, скорее, когда вы извлекаете другую ветку, все файлы в вашей файловой системе изменятся на файлы в этой ветке .Вы просите Git сделать так, чтобы ваша файловая система представляла альтернативную реальность этой ветви.
Если вы находитесь на ветке master, и у нее есть файл root/foo.txt подтверждено, и вы просматриваете ветку experiment, которая не имеет root/foo.txt подтверждено, вынайдет этот файл пропал , когда вы будете искать его.Он является частью master, а не experiment, поэтому его нет в вашей файловой системе.Вот почему Git действительно требователен к тому, что ваша текущая ветвь фиксируется до того, как она позволяет вам переключать ветки - если у вас есть неостановленные изменения в вашей файловой системе, о которых Git не знает, он отказывается их удалять, перезаписывая их другой реальностью.Сначала нужно вмешаться, чтобы все исправить.
Итак, чтобы ответить на вопрос, не создавайте подкаталоги для «myliveapp» и «devapp» - создавайте различные ветви .Просто создайте одну кодовую базу под "webroot".Затем, взломайте, скажем, «нестабильную» ветку, фиксируя ваши изменения как обычно.Затем вы можете переключить все файлы в вашем хранилище на версию файлов вашего сервера разработки, переключившись на ветку «devapp», и вы можете аналогичным образом переключиться обратно на «нестабильный» в любое время.
Когда вы захотите обновить ветку, например, выполнив обновление вашего dev-сервера, вы можете merge «unstable» в «devapp».Это сделает все файлы «devapp» похожими на «нестабильные», обновляя их до даты.
Еще одна вещь, на которую следует обратить внимание: разница между основным репо, голым репо и клонамипочти нольВ программном обеспечении практически нет различий;скорее, это человеческое соглашение: «Ядро Линуса - это каноническое ядро Linux».С этим пониманием:
- Простое репо - это всего лишь один репозиторий, который, как все согласны, содержит «каноническую» версию программного обеспечения.То есть всякий раз, когда разработчик вносит изменения, они хотят, чтобы все увидели, вместо того, чтобы сказать: «Потяните мою версию devapp», они могут сказать: «Я опубликовал свои изменения в нашем основном репо».Люди просто сплачиваются.
- Клон - это копия какого-то другого репо.Я мог бы клонировать основной репо, внести изменения, а затем вы можете клонировать мой репо.Если вы вносите изменения, вы можете поместить их либо в основной репозиторий, либо в мой, при условии, что слияние действительно и у вас есть разрешения на компьютере.
- У чистого репо просто нет «рабочей копии» -на этом компьютере нет каталога "webroot".Он пуст с каталогом only
.git - это хорошо для серверов, где никто не должен изменять файлы.
Наконец, каталог .git не содержитфайлы вашего репо, он содержит конфигурацию git и базу данных.Это вся ваша история репозитория в форме базы данных, которая используется для заполнения остальной части репо определенной версией вашего программного обеспечения.Вот почему я сделал комментарий: вы можете локально проверить любую версию любой альтернативной реальности хранилища, без сетевого взаимодействия, в любое время - потому что все это есть в.Git Dir.Единственное необходимое сетевое взаимодействие - это когда вы хотите синхронизировать ваш локальный репозиторий с другим репозиторием, используя push или pull.