# NexHost Git > Create, clone, and connect a NexHost-hosted Git repository to a service. Source: https://nexthomelabs.com/docs/git Markdown: https://nexthomelabs.com/docs-md/git Slug: git Section: Operate Last updated: 2026-08-30 Reading time: 6 min read --- # NexHost Git NexHost Git provides **hosted repositories that can be selected as a service source**. Rather than coupling the platform to an external code host, workspaces can own repositories directly on NexHost, manage visibility there, and choose that repository as the source when they create or reconfigure a service. Repository access is managed through the dashboard and the [Next CLI](/docs/cli) — the CLI handles authentication and the Git operations; the dashboard handles wiring that repository to a deployment. The mental model is three hops: **create the repository, push source into it, connect it to a service**. A push does not by itself change a live release — deployments are created or triggered from the service in the dashboard. ## When to use NexHost Git vs another source **Choose NexHost Git when:** - You want repository ownership and deployability to live inside the workspace — useful for small teams, platform-internal services, or cases where the source does not belong on a public Git host. - You want to provision repositories from the CLI (`next repo create …`) and keep credentials out of remote URLs. **Stay with another source when:** - The source already lives in GitHub/GitLab/your organization’s preferred Git host and the team would be fragmented by duplicating it. - A public Git URL is the intended source and read-only fetch is sufficient. ## Create a repository Open **Dashboard → Repositories** and create a repository in the intended workspace. Choose its visibility and copy the clone information presented by the dashboard. The dashboard is authoritative for the workspace-qualified name (`YOUR_WORKSPACE/your-repository`) — copy it rather than reconstructing it. You can also create a repository from the CLI — this is often faster when you are provisioning several services: ```bash next login --team YOUR_WORKSPACE next repo create my-service --private ``` What that gives you: - A hosted repository named `YOUR_WORKSPACE/my-service` with the visibility flag you set (`--private` keeps it private to the workspace). - A credential-safe remote URL materializing only via the CLI checkout flow — `next clone` and the credential helper cooperate so the remote URL itself never has to contain a token. - The workspace as the ownership boundary — only principals in `YOUR_WORKSPACE` can see or push to that repository. > [!TIP] > Match the repository name to the service it will back wherever possible (`my-service` rather than `test-2026-temp`). The dashboard displays the exact repository name in the deployment detail, so readable naming reduces triage friction during incidents. ## Push source After creation, push the initial source via the CLI: ```bash next clone YOUR_WORKSPACE/my-service cd my-service next add . next commit -m "Initial service" next push ``` Each step in more detail: - **`next clone YOUR_WORKSPACE/my-service`** — clones via the platform credential helper rather than a token-bearing URL. - **`next add .` / `next commit`** — the usual Git staging/commit cycle, operating on whatever branch you are on. - **`next push`** — pushes to the hosted remote on the current branch. Private visibility stays enforced workspace-side. - **`next doctor`** — if authentication or the local Git configuration is not ready, `doctor` is the one-line health check for credential helper and Git wiring. The CLI keeps credentials out of repository remote URLs, so a `git remote -v` does not leak a session token even if you paste it in a shared doc. If you do need to share the remote instruction, share the **qualified label** (`YOUR_WORKSPACE/my-service`) rather than a computed URL. > [!WARNING] > Do not commit secrets to the hosted repository — connection strings, tokens, and private keys belong in service-scoped [Environment Variables](/docs/configuration/environment-variables). A repository commit containing a secret is still a secret in history even after you rotate it. ## Branches, visibility, and ongoing development NexHost Git repositories use **standard Git branches**. Selecting a branch for a service happens on the service itself — during **New Project** and later when you reconfigure the service to track a different branch. Typical lifecycle: 1. Create the repository with the desired visibility. 2. Push `main` (or your team’s default branch) and verify the branch appears on the repository screen. 3. Wire the service to that repository + branch in **New Project**. 4. For everyday development, push feature branches normally and let the service review a staged branch before promoting. > [!INFO] > The platform makes no assumption that `main` is the only deployable branch. Point the service at whichever branch represents the desired cut for that service; updating the branch on the service is the act of retargeting. ## Connect it to a service During **New Project**, choose **NexHost Git as the source** when it is offered, select the **repository and branch**, then review the service’s build, start, or publish settings before deploying. Pay particular attention to the *Root directory* when the repository is a monorepo — the path should point at the package that contains the build manifest (`package.json`, `requirements.txt`, `go.mod`), not at the repository root. What happens after the wiring: - A **source push** does **not by itself** change a live release. After you push fresh commits, go to the service and start or configure the deployment from the dashboard so the platform records a new release with that updated source. - The deployment detail records **which repository + branch + commit** produced each release, along with the captured build and launch settings. Future comparisons between a working and a broken release read that provenance. - Framework detection, output directory, build log, and timestamps are captured per release as well, so you can diff two releases even when Git history alone is unclear. > [!TIP] > Review the captured Git commit and root directory captured on the release detail before you assume a deployment honors the most recent push. A mis-pointed branch or an un-pushed local commit will surface there first. ## Troubleshooting | Symptom | Likely cause | Fix | | --- | --- | --- | | `not authenticated` on clone/push | No active workspace session or wrong `--team` | `next login --team YOUR_WORKSPACE` (or `--device` on headless sessions), then `next whoami` to confirm | | Repository not listed in New Project source selector | Repository is in a different workspace | Open Repositories inside the **active** workspace and verify the qualified name `YOUR_WORKSPACE/your-repo` there | | Push succeeds but release still shows old commit | Service branch points at a different branch than the push | Reopen the service, change the branch in source settings, and start a new deployment | ## Related documentation - [Next CLI](/docs/cli) — full install, auth modes, and the `doctor` health check. - [Deployments](/docs/deployments) and [Logs](/docs/operations/logs) — reading the per-release record of which source actually ran. - [Your First Deployment](/docs/getting-started/your-first-deployment) — the numbered dashboard path from source to verified hostname.