Repositories

Create, manage, and configure Git repositories with S3-backed storage.

What Are Repositories?

Repositories in Bosca Git are standard Git repositories hosted on the platform. They work with any Git client — you clone, push, pull, and branch exactly as you would with any other Git remote. Under the hood, repository object data is stored in S3-compatible storage rather than local disk, which enables stateless, horizontally scalable Git server deployments.

Each repository belongs to either a user or an organization. Organizations are the typical owner for team projects, while user-owned repositories are useful for personal experiments, forks, or draft work before transferring to an organization.

Creating a Repository

When you create a new repository, you choose a name and an owner (your user account or an organization you belong to). You can optionally initialize the repository with starter files:

README — A default readme file so the repository is not completely empty on first clone.
.gitignore — A language- or framework-specific ignore file to keep build artifacts and temporary files out of version control.
LICENSE — A license file selected from common open-source licenses.

If you skip initialization, the repository starts empty and you push your first commit from your local machine.

Initializing with at least a README is recommended. It gives the repository a default branch immediately, which is required before you can configure branch protection rules or open pull requests.

Repository Settings

Visibility

Every repository has a visibility level that controls who can discover and access it:

Visibility	Who Can See It
Public	Anyone, including unauthenticated users. Suitable for open-source projects or public documentation.
Internal	Any authenticated user on the platform. Useful for company-wide code that should be visible across teams but not publicly.
Private	Only users who have been explicitly granted access through group permissions. The default for most team projects.

Default Branch

The default branch is the branch that is shown when someone visits the repository, and the target branch that new pull requests are opened against unless the author specifies otherwise. You can change the default branch at any time in the repository settings.

Allowed Merge Strategies

Bosca Git supports four merge strategies for pull requests. Repository administrators can enable or disable each one to enforce a consistent merge policy across the team:

Strategy	Behavior	Best For
Merge Commit	Creates a merge commit that joins the source and target branch histories. Both branches remain visible in the history graph.	Teams that want a clear record of when branches were integrated.
Squash	Combines all commits from the source branch into a single commit on the target branch. The individual commits are collapsed.	Keeping the main branch history clean when feature branches have many small or work-in-progress commits.
Rebase	Replays the source branch commits on top of the target branch, creating new commits with the same changes but different parent hashes.	Maintaining a linear history while preserving individual commit granularity.
Fast-Forward	Moves the target branch pointer forward to the tip of the source branch. Only possible when the target has no new commits since the source branched off.	Strictly linear workflows where branches are always rebased before merging.

Additional Settings

Auto-delete source branch on merge. When enabled, the source branch of a pull request is automatically deleted after a successful merge. This keeps the branch list tidy without requiring manual cleanup.
GPG signature enforcement. When enabled, the platform rejects pushes that contain unsigned commits. This ensures every commit in the repository can be verified as coming from the claimed author.

Content Type Classification

Repositories can be classified by content type, which tells the platform what kind of project the repository contains. This classification affects how the platform interacts with the repository:

Content Type	Purpose
General	A standard code repository with no special platform behavior. This is the default.
BX Project	A project tied to Bosca's experience management features.
Script Project	Contains platform scripts. The platform can load and execute scripts directly from this repository.
Documentation	Contains documentation content that can be published through the platform's content system.
Analytics Query Project	Contains saved analytics queries. Queries stored here benefit from version control and code review before being deployed.

Forking

Forking creates a linked copy of a repository under a different owner. The fork shares the parent repository's underlying object store, which means the fork operation is fast and does not duplicate storage for existing objects. New commits pushed to the fork are stored independently.

Forks are commonly used for contribution workflows: a contributor forks a repository, makes changes in their fork, then opens a cross-fork pull request to propose merging those changes back into the parent repository. This pattern is especially useful for open-source projects or when contributors do not have push access to the upstream repository.

The fork relationship is tracked by the platform. You can always see which repository a fork was created from, and the parent repository lists all of its forks.

Archiving

Archiving a repository marks it as read-only. All existing content — branches, tags, commits, pull requests, and history — is fully preserved and remains accessible. However, no new pushes are accepted and no new pull requests can be opened or merged.

Archiving is reversible. If you need to resume development on an archived repository, un-archiving restores it to full read-write operation. This makes archiving a safe choice for projects that are complete or paused — you are not losing anything by archiving.

Soft Delete and Retention

When you delete a repository, it is not immediately destroyed. Instead, it enters a soft-deleted state and is retained for 30 days. During this retention window, the repository can be restored if the deletion was accidental. After 30 days, the repository and its data are permanently removed.

Permanent deletion after the 30-day retention period is irreversible. If you are unsure whether a repository will be needed again, consider archiving it instead of deleting it.

Disk Size Tracking

The platform tracks the disk size of each repository's object store. This lets administrators monitor storage consumption across the organization and identify repositories that may benefit from history cleanup or large file management strategies.

Permissions

Repository access is controlled through group-based permissions, consistent with the rest of the Bosca platform. Three permission levels are available:

Permission	What It Allows
VIEW	Clone and read the repository contents, view branches, tags, commits, and pull requests.
EDIT	Push commits, create and delete branches and tags, open and comment on pull requests.
MANAGE	Change repository settings, configure branch protection, manage webhooks, control access permissions, archive, and delete the repository.

Permissions are assigned to groups, and users inherit access through their group memberships. This means you manage access at the team level rather than granting permissions to individual users.