Terraphim AI implements comprehensive branch protection to prevent private or sensitive code from leaking into the public repository. This system uses multiple layers of protection including pre-push hooks, branch naming conventions, and repository-level security rules.
Terraphim AI uses a dual-repository architecture for security:
- Public Repository (
terraphim/terraphim-ai): Open-source code only - Private Repository (
zestic-ai/terraphim-private): Proprietary and sensitive code
This separation ensures that:
- Open-source development remains transparent and accessible
- Proprietary algorithms and client data stay secure
- Compliance with various licensing and security requirements
The repository includes a sophisticated pre-push hook (.git/hooks/pre-push) that runs before any push to the public repository.
Blocked Patterns:
# Hyphen patterns
private-*, internal-*, client-*, secret-*
wip-private-*, customer-*, proprietary-*, confidential-*
# Underscore patterns
private_*, internal_*, client_*, secret_*
wip-private_*, customer_*, proprietary_*, confidential_*
# Explicit private branches
sqlite_haystack, private-feature, internal-docs, customer-data, private_tfAllowed Patterns:
# Feature branches
feat/new-ui-component
feat/semantic-search
fix/memory-leak
docs/update-readme
refactor/cleanup-code
test/add-unit-tests
# Development branches
wip/experimental-feature
experimental/new-algorithmThe hook scans commit messages for private markers:
Blocked Markers:
[PRIVATE],[INTERNAL],[CLIENT],[DO-NOT-PUSH][CONFIDENTIAL],[CUSTOMER]private:,internal:,client:,secret:,confidential:
Sensitive Keywords Detected:
customer_api_key,client_secret,private_key_prodinternal_endpoint,zestic.*api,customer.*passwordtruthforge,private.*cloud,internal.*api
File Pattern Validation:
- Uses
.gitprivateignorefile for custom patterns - Scans file contents for sensitive data
- Prevents accidental inclusion of private files
The main branch has comprehensive protection rules:
- Required Status Checks: CI-native workflow must pass
- Required Reviews: At least 1 approval required for pull requests
- Admin Enforcement: Even admins must follow protection rules
- Force Push Prevention: Disabled to prevent history rewriting
- Branch Deletion Prevention: Disabled to prevent accidental deletion
- Merge Options: Configured for squash, merge, and rebase
- Auto-merge: Disabled for manual review requirement
- Branch Cleanup: Auto-delete branches after merge
For open-source development:
-
Create feature branch:
git checkout -b feat/new-feature
-
Develop and commit:
git add . git commit -m "feat: add new feature"
-
Push to public repository:
git push origin feat/new-feature
-
Create pull request and wait for review
For proprietary or sensitive development:
-
Switch to private repository:
git remote set-url origin git@github.com:zestic-ai/terraphim-private.git
-
Create private branch:
git checkout -b private-feature # or git checkout -b internal-api -
Develop normally:
git add . git commit -m "feat: add private feature" git push origin private-feature
-
Switch back to public (when ready):
git remote set-url origin https://github.com/terraphim/terraphim-ai.git
For projects that span both repositories:
-
Configure both remotes:
git remote add private git@github.com:zestic-ai/terraphim-private.git
-
Set branch-specific remotes:
git config branch.private-feature.remote private git config branch.private-feature.pushRemote private
-
Develop in appropriate repository:
# For private work git checkout private-feature git push private private-feature # For public work git checkout feat/public-feature git push origin feat/public-feature
✗ Branch 'private_tf' matches private pattern '^private_'
Private branches should not be pushed to public remotes.
Push to private remote instead: git push private private_tfSolution:
# Configure branch to push to private remote
git config branch.private_tf.remote private
git config branch.private_tf.pushRemote private
# Push to private repository
git push private private_tf✗ Sensitive keyword 'truthforge' found in file changes
Remove sensitive content before pushing to public remote.Solution:
- Remove or replace sensitive content
- Use private repository for sensitive development
- Update
.gitprivateignoreif it's a false positive
✗ Found commits with private markers:
1eccff1 [PRIVATE] add sensitive feature
Remove private markers or push to private remote instead.Solution:
- Rewrite commit message without private markers
- Use
git commit --amendto fix the message - Or push to private repository
# Check current remote configuration
git remote -v
# Add private remote if missing
git remote add private git@github.com:zestic-ai/terraphim-private.git
# Configure branch for private remote
git config branch.branch-name.remote private
git config branch.branch-name.pushRemote private# Check if hook exists and is executable
ls -la .git/hooks/pre-push
# Make executable if needed
chmod +x .git/hooks/pre-push
# Test hook manually
.git/hooks/pre-push origin https://github.com/terraphim/terraphim-ai.gitThe pre-push hook logs all push attempts to .git/push-audit.log:
# View recent push attempts
tail -f .git/push-audit.log
# Example log entry
2025-01-08 19:33:22 - SUCCESS: Push to origin from feat/new-feature
2025-01-08 19:35:15 - BLOCKED: Push to origin from private_tf (private pattern)- Failed push attempts are logged with timestamps and reasons
- Sensitive content detection is logged for security monitoring
- Branch pattern violations are tracked for compliance
Create a .gitprivateignore file to define custom file patterns:
# Example .gitprivateignore
**/private/**
**/internal/**
**/client-data/**
**/*.secret
**/config/production.*Update sensitive keywords in .git/hooks/pre-push:
sensitive_keywords=(
"customer_api_key"
"client_secret"
"private_key_prod"
"internal_endpoint"
"zestic.*api"
"customer.*password"
"truthforge"
"private.*cloud"
"internal.*api"
# Add your custom keywords here
)- Use descriptive names:
feat/semantic-searchnotfeat/ss - Follow conventions:
type/descriptionformat - Avoid private patterns: Use public repository for open-source work
- Be consistent: Follow team naming conventions
- Use conventional format:
type(scope): description - Avoid private markers: Don't use
[PRIVATE],[INTERNAL], etc. - Be descriptive: Explain what the commit does
- Keep it concise: One line summary, detailed body if needed
- Use appropriate repository: Public for open-source, private for proprietary
- Configure remotes properly: Set branch-specific remotes when needed
- Keep repositories in sync: Regular updates between public and private
- Document private features: Use private repository for sensitive documentation
- Review before pushing: Always check what you're pushing
- Use private repository: For any sensitive or proprietary code
- Update patterns: Add new sensitive keywords as needed
- Monitor logs: Check push audit logs regularly
- Train team members: Ensure everyone understands the protection system
The pre-push hook can be customized by editing .git/hooks/pre-push:
# Add new private branch patterns
private_branch_patterns=(
"^private-"
"^private_"
"^internal-"
"^internal_"
"^custom-pattern-" # Add your pattern here
)
# Add new sensitive keywords
sensitive_keywords=(
"customer_api_key"
"client_secret"
"custom_sensitive_key" # Add your keyword here
)Set up global or repository-specific configurations:
# Global configuration
git config --global branch.autoSetupRemote true
# Repository-specific configuration
git config branch.private-feature.remote private
git config branch.private-feature.pushRemote privateMost IDEs can be configured to work with the dual-repository setup:
- VS Code: Use GitLens extension for remote management
- IntelliJ: Configure multiple remotes in VCS settings
- Vim/Neovim: Use fugitive.vim for Git operations
- License compatibility: Ensure all public code is properly licensed
- Attribution requirements: Include proper copyright notices
- Dependency management: Track and document all dependencies
- Data protection: Ensure no sensitive data in public repository
- Access controls: Properly manage repository access
- Audit trails: Maintain logs for compliance requirements
- Client data: Never commit client-specific data to public repository
- Proprietary algorithms: Keep proprietary code in private repository
- NDA compliance: Ensure all work respects non-disclosure agreements
This comprehensive branch protection system ensures that Terraphim AI maintains the highest security standards while enabling efficient development workflows across both public and private repositories.