GitHub Organization Setup (Jaribu Tech Solutions) — Obsidian Notes

Overview

This document covers the full setup of a GitHub Organization for Jaribu Tech Solutions, including security settings, structure, and best practices for managing personal vs company development.

1. Organization Decision

Choice Made:

• Organization Type: Business or Institution
• Name: Jaribu Tech Solutions
• URL: https://github.com/Jaribu-Tech-Solutions
• Contact Email: support@jaributechsolutions.com

Why this choice:

• Separates personal identity from company assets
• Enables team collaboration
• Allows structured repo management
• Scales properly for future developers

2. Identity Structure

Recommended Setup:

Personal GitHub

• Used for:
  • Personal projects
  • Open source contributions
  • Learning experiments
• Email used in commits:
  • personal email (recommended for visibility)

Jaribu Tech Organization

• Used for:
  • Company projects
  • Client systems
  • Production code
• Owned by personal account (YOU are Owner)

3. Repository Structure

Inside Organization:

• company-website
• client-portal
• inventory-system
• crm-system
• marketing-site

Rule:

All company code MUST live inside the organization.

4. Teams Setup

Create teams early (even if solo):

Suggested Teams:

• Owners
• Developers
• Designers
• Interns

Permissions:

• Owners → Full control
• Developers → Write access
• Interns → Read-only

5. Security Settings (CRITICAL)

Navigate:
Organization → Settings → Code security and analysis

Enable:

1. Push Protection

• Blocks commits with secrets (API keys, passwords)
• Prevents accidental leaks

2. Dependency Graph

• Tracks project dependencies
• Enables vulnerability detection

3. Dependabot Alerts

• Alerts when libraries have security issues

4. Dependabot Security Updates

• Auto-creates PRs to fix vulnerabilities

5. Grouped Security Updates (Optional)

• Groups dependency updates into fewer PRs

6. Private Vulnerability Reporting

• Allows private reporting of security issues

6. Important Security Mindset

Biggest real risks (NOT enterprise features):

• Committing .env files
• Hardcoding API keys
• Pushing secrets to GitHub
• Wrong Git identity usage

Must-have protections:

• .gitignore for all projects
• Push protection enabled
• Manual commit review discipline

7. Git Identity Rules

For Company Repos:

git config user.name "Mati"
git config user.email "personal-email@gmail.com"

Why:

• Keeps your GitHub contribution graph active
• Maintains personal developer identity
• Still pushes to company-owned repos

8. SSH Setup (Dual Account System)

Keys:

• github_personal
• github_company

SSH Config:

Host github-personal
HostName github.com
User git
IdentityFile ~/.ssh/github_personal

Host github-company
HostName github.com
User git
IdentityFile ~/.ssh/github_company

Clone Example:

git clone git@github-company:Jaribu-Tech-Solutions/repo.git

9. Organization Profile Setup

Must Add:

• Logo
• Description
• Website link
• Contact email

Optional:

• README profile repository (.github)
• Company landing page inside GitHub

10. Workflow Structure

Development Flow:

1. Create repo inside org
2. Clone using SSH alias
3. Set git identity per repo
4. Commit with personal email
5. Push to org repo
6. Protect main branch (recommended later)

11. Critical Rules (DO NOT BREAK)

• NEVER store secrets in repos
• NEVER use random GitHub account for company code
• ALWAYS use organization repos for business projects
• ALWAYS enable push protection
• ALWAYS check git config before first commit

12. Mental Model

Think of it like:

Personal GitHub = Your developer identity
Organization = Company infrastructure
Repos = Products

End of Setup

This setup scales from solo founder → agency → real company without restructuring later.