Git workspace

Workspace → Git discovers checkouts under JD_GIT_ROOTS (default /opt,/srv,/home,/root); those paths must also be mounted into the backend container at the same location. It works as the Linux account that owns each checkout, so changes made in the dashboard do not leave root-owned files in someone else's repository.

Review and publish a changeCopy Anchor Link

1. Choose a repository from the list. Its card shows branch, last commit, languages, upstream position, and whether conflicts or uncommitted files need attention. The list puts urgent states first, and linked worktrees have a section of their own.
2. Open Changes to inspect staged and unstaged versions of each file. Select whole files, changed chunks, or individual lines for staging where the diff supports it. A file edited again after staging appears on both sides. Alt+Up and Alt+Down walk the changed files.
3. Set a committer identity if the repository has none, enter a message, and commit. Fetch, pull, and push share one control. Pull is fast-forward only, so it will not silently create a merge; it sets a missing upstream when there is one clear match and otherwise asks you to choose one under Branches. Push establishes an upstream when one is missing and never forces a remote rewrite.
4. If local changes or folders owned by another account block a pull, the dashboard lists what is in the way and offers to stash the changes, discard them, or give the folders back to the checkout's owner. Each choice pulls afterwards; stashing keeps everything.
5. Use History and Branches to inspect commits, compare branches, create or switch branches, work with tags, or recover an earlier commit. A commit's file list opens its diff in the preview column, where you can also read blame and signature checks.

Add repository can clone into a new directory under an allowed root or initialize an existing directory. Clone supports a chosen branch or tag, shallow depth, and sparse directories. The More git actions menu holds stash, remotes, Worktrees, Who commits here, Recovery timeline, Edit local history, Submodules, Git LFS, Patch exchange, and shortcuts to open the checkout in Files or Terminal. History editing creates a recovery branch first; selected-line staging and conflict resolution check that the file has not changed since you opened it.

Work with pull requestsCopy Anchor Link

The GitHub view uses the account of the checkout owner. Select Sign in and complete GitHub's device flow, then use the view to inspect pull requests, changed files, reviews, checks, and Actions job logs, to comment, or to open and merge a request. The same login can support terminal and SSH Git operations when the host has gh installed and configured for that account.

For GitLab or Gitea requests, connect a provider token in More git actions → GitLab and Gitea. Tokens are encrypted on the server and scoped to the checkout and its Linux owner; moving the checkout or changing owner requires reconnecting. Git pushes still use the owner's existing SSH keys or credential helper. GitLab accepts comments for request-changes feedback while Gitea offers a request-changes review. The source branch must already be pushed before opening a request.

Discarding work, a hard reset, and dropping a stash ask for confirmation because they can remove uncommitted changes. Delete from server… removes the checkout itself and asks you to type its name first.