Git / Gitea Repository Usage Policy

[- Alex - 36]

Git / Gitea Repository Usage Policy
Repository Access, Security & Collaboration
Public GGU policy — subject to revision as systems, responsibilities, and operational practices change.

Public Transparency:
This policy is intentionally published so the community can understand GGU's standards and accountability. Credentials, recovery material, private personnel records, and active security-sensitive details remain restricted.

This policy defines acceptable use, security, permissions, and collaboration standards for GGU Git repositories hosted in Gitea or any future approved source-control platform.

 

Scope

This policy applies to all authorized repository users, including Leadership, Development, approved contributors, automation accounts, and authorized partners.

 

Repository Access

• Access only repositories required for your responsibilities.
• Use the lowest permission level that supports your work.
• Repository Admin access should be limited to maintainers who need to manage settings or permissions.
• Private repository content must remain private unless publication is approved.

 

Account Security

• Protect your Gitea account with strong credentials and two-factor authentication where supported.
• Protect SSH private keys and personal access tokens.
• Remove keys from lost or retired devices.
• Never place tokens, passwords, or private keys in repository content, issues, pull requests, or screenshots.

 

Branches & Pull Requests

• Use feature/fix branches for changes that benefit from review.
• Respect protected branch requirements.
• Do not weaken branch protection merely to make one change easier.
• Use pull requests where review is required or appropriate.
• Describe what changed, why, and how it was tested.

 

Direct Pushes

Direct pushes to important branches should be restricted where appropriate. Even where technically allowed, contributors should use the repository's expected workflow.

 

Commits

• Use meaningful commit messages.
• Keep commits understandable and reasonably focused.
• Do not deliberately hide unrelated changes inside a commit.
• Do not rewrite shared history without a clear reason and authorization.
• Do not commit generated binaries unless the repository intentionally tracks them.

 

Secrets

Critical:
Secrets do not belong in Git history. If a secret is committed, rotate or revoke it immediately. Deleting it from the latest commit does not make it secret again.

• Use placeholders in tracked example configuration files.
• Use approved secret-management or deployment mechanisms for real credentials.
• Treat Gitea Actions secrets and deploy credentials as security-sensitive.
• Review public/open-source repositories carefully before publication.

 

Pull Request Review

Review should consider correctness, security, compatibility, configuration changes, migrations, deployment impact, testing, and rollback where relevant.

 

Repository Permissions

Where practical, use organization teams to manage access by responsibility. Permissions should be reviewed after role changes, project completion, extended inactivity, or security incidents.

 

Releases & Tags

• Use consistent versioning where the project releases deployable versions.
• Do not casually move published release tags.
• Document breaking changes or required configuration migrations.
• Confirm release artifacts do not contain secrets.

 

Force Pushes & History Rewriting

Force-pushing protected or shared branches is prohibited unless explicitly authorized for an exceptional recovery case. Prefer revert commits for correcting changes that have already been shared.

 

External Contributions

External or partner contributions may be accepted when authorized and should follow the same security, review, and licensing standards as internal contributions.

 

Repository Archival

Retired repositories should normally be archived rather than deleted when they retain historical, operational, or recovery value. Document replacements and retirement status.

 

Prohibited Use

• Publishing private GGU source without authorization.
• Committing secrets or private member data.
• Bypassing review or branch protection without authorization.
• Deleting repositories or history to conceal mistakes.
• Using GGU repositories to distribute malicious or unauthorized content.
• Copying third-party code or assets without respecting licensing requirements.

 

Violations

Violations may result in repository access removal, corrective action, disciplinary review, or additional action depending on severity.

 

Related Documentation

• Source Code & Intellectual Property Policy
• GGU Branch & Pull Request Workflow
• Git Secrets & Environment File Guide
• Repository Permissions & Protection Guide
• Rollback & Revert Procedure

 

Protect the codebase, preserve review, and keep repository history trustworthy.

Edited Saturday at 07:54 AM by - Alex -
Updated Policy