Documentation
Quickstart
Create a repository, authenticate Git, push a branch, and open a Change Request.
This guide starts from a new Upstream repository and takes you to your first reviewed change. For an existing project, read the local upload guidance before changing remotes or pushing history.
1. Create an account
Create an Upstream account. Your handle becomes the namespace for your personal repositories. The same identity also works across Coline.
2. Create a repository
Open Repositories, select New repository, choose a namespace, name the repository, and set its visibility.
- Public repositories are visible and cloneable without signing in.
- Private repositories require explicit access.
- Internal repositories are visible to members of the owning workspace.
3. Set up Git authentication
Public repositories can be cloned without a credential. For HTTPS pushes, run upstream auth login; it also configures Git. You can also create a Git credential in Git settings.
For HTTPS, use any non-empty username and the one-time credential as the password.
4. Push to main
New repositories are empty and allow direct pushes to main. Copy the canonical clone URL from the repository page. To start a new project:
git clone https://git.coline.app/{namespace}/{repository}.git
cd {repository}
git switch -C main
# Make your changes, then stage the files you intend to commit.
git add path/to/changed-file
git commit -m "Describe your change"
git push -u origin main
To upload an existing project, add the clone URL as a remote and push your local main branch with git push -u upstream main:main. Keep any existing remotes. Confirm the remote main commit matches your local commit. If the destination already has history, fetch and reconcile it first; do not overwrite it with a force-push.
5. Open a Change Request when you want review
Change Requests are optional unless an administrator enables branch protection. Push a separate branch, open the repository on upstream.codes, select Changes, then New Change Request. Choose the source and target branches, describe the change, and create the request.
Each later version keeps its own review and check history. An approval of an older version never silently approves newer code.