The mapped drive is not a git working copy

Misconception By design
A Docly workspace mapped as a drive is not a git working copy, and running git init inside it creates a .git directory in the live application on a slow network filesystem. But Docly does support git: install the git-credential-docly helper and clone the folder with git clone https://<instance>/git/<Folder>, then work locally and push back.
Applies to: Workspace setupAI agents

What you'll see

Someone — often an AI coding agent on its first pass — opens a mapped Docly drive, finds no .git directory, and runs git init to get version control before starting work. Or the opposite: they are told "Docly has no git", accept it, and spend the project editing production directly with no history at all.

Both are wrong, in opposite directions.

What's actually happening

The mapped drive is a WebDAV mount of the live application. There is no working copy there because the files are the running site. Running git init against it does not give you version control of your deployment — it creates a .git directory inside the application, on a filesystem where every object read and write is an HTTP round trip. The result is a repository that is slow to the point of unusable, sitting in a folder your non-developer users can see, tracking a tree that changes underneath it whenever anyone edits through the Docly UI.

But Docly does speak git. Every folder is exposed as a git repository at https://<instance>/git/<Folder>. Authentication goes through a small credential helper rather than a password: git always sends credentials as HTTP Basic, and Docly does not accept an account password there, so git-credential-docly opens your browser, you sign in normally — including two-factor — and it hands git a short-lived token. Access follows the same rules as the rest of Docly; you clone only what you can already see.

Once cloned you have an ordinary local repository. Branch, rebase, commit as often as you like; nothing reaches the live site until you push. That is a genuinely different workflow from the mapped drive, and for anything with a review step it is the better one.

What to do

On a mapped drive: never git init. If you want history there, copy files out before editing — see Work safely on a live site.

To use git properly, clone instead. Full instructions, including the download links for each platform, are in Using Git with Docly. In short:

# 1. Put git-credential-docly on your PATH (name must be exact)

# 2. Once per Docly instance - note: NO trailing slash
git config --global credential.https://docly.net.helper docly

# 3. Clone
git clone https://docly.net/git/Projects

# 4. Work normally
git add .
git commit -m "Updated the report"
git push

A trailing slash in step 2 silently fails to match, and git falls back to asking for a password — which does not work. If the helper is not found, check the filename: git locates it by looking for a program called exactly git-credential-docly.

Choosing between the two

Mapped drivegit clone
Change goes liveOn save, immediatelyOn git push
HistoryNone — back up manuallyFull local history
Review before publishNot possibleBranch and diff first
SpeedEvery operation is an HTTP round tripLocal disk
Good forFast iteration, throwaway pages, low-risk sitesAnything transactional, login-protected or high-traffic

Whichever you pick, state it explicitly in the workspace's agent instruction file so an agent does not have to guess — see Set up AI agent instruction files for a workspace.