GitBlixt
Docs Navigation

Repositories

A repository holds your code, history, branches, issues, merge requests, and more. This page covers creating, browsing, cloning, forking, and configuring repositories.

Creating a Repository

  1. Click New repository or go to /new.
  2. Choose the Owner — your personal account or any organization where you have write access.
  3. Enter a name. Names may contain only letters, numbers, dots, hyphens, and underscores. Availability is checked as you type.
  4. Optionally add a Description.
  5. Pick a Visibility:
    • Public — anyone can see the repository.
    • Private — only you and collaborators can see it.
  6. Click Create repository.

New repositories are created with a default branch of main and a starter set of labels. The repository starts empty — the repository page shows the commands to push your first commit.

Browsing Code

The repository page shows the file tree for the current branch. From the toolbar you can:

  • Switch branch or tag using the branch dropdown (labeled with the current ref). Branch and tag counts link to the full Branches and Tags pages.
  • Use Go to file to fuzzy-search any file in the current ref.
  • Click a file to open the blob view; click a directory to descend into the tree.
  • Click New file to create a file directly in the browser (signed in).

URLs follow /:namespace/:repo/tree/:ref/path for directories and /:namespace/:repo/blob/:ref/path for files, so you can link to a specific ref and path. A ref may contain slashes, as in tree/feature/login/lib: the longest branch or tag name the path starts with is the ref. An unknown ref shows the default branch.

Cloning

The repository page has a Clone box with a copy button. Clone over SSH:

git clone [email protected]:namespace/repo.git

Or over HTTPS:

git clone https://git.michlp.com/namespace/repo.git

For HTTPS with a private repository, authenticate with a personal access token — see Personal Access Tokens.

Forking

  1. Open the repository and click Fork.
  2. If you belong to more than one eligible account, choose where to fork into (your personal account or an organization where you have write access).
  3. Click Create fork.

The fork keeps a link to its upstream. On the forked repository's page, use Sync to pull in new commits from the original.

Viewing Forks

The fork count next to the Fork button links to the forks list at /:namespace/:repo/-/forks, showing each fork's namespace, visibility, and fork date.

Collaborators

Repository owners add collaborators under Settings → Collaborators. Enter a username, pick a role, and click Add. Roles can be changed inline, and collaborators removed, at any time.

Role Typical access
guest Read code and issues (also in private repositories), open issues and comment, close their own issues. Cannot label, assign, push or change settings.
reporter Everything a guest can, plus label, assign, close and reopen any issue, and label merge requests and set their reviewers. Cannot push or change settings.
developer Push code, create branches and merge requests, merge (subject to protected-branch rules) and edit any issue. In an organization, also create repositories.
maintainer Everything a developer can, plus webhooks, CI/CD variables, protected branches, environments and their variables.
owner Everything, including deleting, renaming, transferring or changing the visibility of the repository. An organization owner also manages its members, teams and settings.

Contributors Graph

The contributors graph at /:namespace/:repo/-/graphs/contributors charts commits over time (excluding merge commits) for the whole repository and per contributor. Use the Period dropdown to scope the view to the last month, 3, 6, 12, or 24 months, or all time.

Repository Settings

Only the repository owner can open Settings (the gear icon, or /:namespace/:repo/-/settings). Sections include:

  • General — rename the repository, edit its description, change visibility between public and private, choose the default branch, and turn CI/CD on or off.
  • Collaborators — add, re-role, and remove collaborators (see above).
  • Webhooks — manage outgoing webhooks. See Webhooks.
  • Protected branches — prevent force-pushes and control who may push and merge. Supports wildcards (e.g. release-*).
  • Approval rules — require a number of approvals before a merge request can be merged.
  • Branch rules — per-branch merge requirements: minimum approvals, CI must pass, and no conflicts.
  • Mirroring — push or pull mirror to GitHub, GitLab, another GitBlixt instance, or any git remote. See Repository Mirroring.
  • CI/CD Variables — environment variables injected into CI job containers, with masked and protected options.
  • Fetch from remote — queue a one-time fetch from an external repository.
  • Deployment — enable the built-in PaaS for this repository. See App Deployment.
  • Danger zone:
    • Transfer — move ownership to your personal account or another organization you own. The repository's namespace changes accordingly.
    • Delete — permanently remove the repository. This cannot be undone.