v1.4.0

A repository no longer has to belong to one person. Create an organization from the "+" menu, and it gets its own page at /your-org with its own repositories, its own members, and roles for them: owner, admin, member. Owners and admins can create and push; members can read.

Organizations share the top-level URL namespace with people, so /acme is either a user or an organization and never both. Existing usernames were already claimed and keep working; a new organization can't take one, and neither can a new account take an organization's.

#Forks

Any repository you can read can be forked, into your own account or into an organization you administer. The fork carries the full history, and a fork of a private repository stays private.

A fork keeps a link back to where it came from. "Sync fork" fast-forwards a branch to its upstream, and refuses rather than guesses when the fork has commits of its own to merge first.

#Pull requests from a fork

A branch in a fork can be proposed to the repository it was forked from, which is what makes drive-by contribution work: you need write access to your fork and read access to the repository you're proposing into, not write access to someone else's project.

The compare branch is written owner:branch, the same shorthand the pull request page then shows. Pushing to the fork updates the pull request.

#Reviews on the diff

Pull requests now take a formal review: approve, request changes, or comment. Comments can be anchored to a line of the diff, replied to as a thread, and resolved when the conversation is done. Batching comments into a review keeps them private until the review is submitted.

Pull requests can also be opened as drafts, merged with a squash instead of a merge commit, and close the issues their body says they close.

#Branch protection

A repository's settings page can now require things of a pull request before it merges: a number of approving reviews, passing status checks by name, and every conversation resolved. Stale approvals can be dismissed when new commits land.

Nothing is on by default. A repository that never opens the settings page merges exactly as it did before.

Status checks arrive over an API shaped after GitHub's, so an existing CI integration only has to change its base URL:

POST /api/v1/repos/:owner/:repo/statuses/:sha
GET  /api/v1/repos/:owner/:repo/commits/:sha/status

#siGit Code Review runs on sigit.si

siGit Code Review used to review pull requests on github.com only. The reviewer is now generic over hosts and reviews pull requests here too, posting as the sigit-code account: a walkthrough summary plus line comments, in the same review UI a person writes into. It's opt-in per repository, and it spends the owner's cloud allowance.

#Sessions tab

Repositories have a Sessions tab showing the siGit Code Cloud sessions held against them. A session is private to whoever held the conversation, so the list is always your own, even on a repository you own.

#Labels and assignees

Issues and pull requests share a per-repository label set, seeded with the usual starting vocabulary when a repository is created. Both can be assigned, and pull requests can request a review from someone.

#Cloud allowances that reset again

A subscription's billing period was derived from a mirror of Stripe that only moved when a webhook was processed. Stripe moved the field the sync read, every customer.subscription.updated since July raised on it, and the period key froze: usage accumulated into a bucket that could never roll over, so affected accounts were capped with nothing on the page to explain it.

The sync now reads the field from both of the shapes Stripe uses, and the period key falls back to the calendar month when the mirror looks stale. Affected accounts recover on their next request; nothing needs to be re-entered.

#Diffs with line numbers

Diffs are parsed into files, hunks, and lines instead of being rendered as one block of text, so both sides carry real line numbers and a comment can be anchored to one of them.