GitHub Organization
Executive Summary
A Complete Guide for Startup Owners
Prepared for leadership review • Confidential
■ 1. What Is a GitHub Organization?
A GitHub Organization is a shared account that represents your company — not any one individual. Your personal
GitHub is your passport; the Organization is your company's office building. Even if a founder leaves or a co-founder
walks out, the code, the team, and the full history remain intact and accessible. This is the single most important reason
every startup should set one up before writing their first line of code.
When you own a startup, the question you must ask is: what happens to all our code if something happens to me, or if
someone leaves? The answer to that question is exactly why GitHub Organizations exist.
Aspect Personal Account GitHub Organization
Ownership One individual person The company as an entity
If owner leaves Code may become inaccessible Code stays — company continues
Team management Per-repo collaborators only Role-based Teams across all repos
Billing Individual subscription One central company bill
GitHub URL [Link]/your-name [Link]/your-startup-name
Audit logs Not available Available on Team & Enterprise plans
Branch protection Basic only Advanced (Team plan)
Investor due diligence Red flag for investors Clean and professional
Recommended? ■ No ■ Always — from day one
■ Setting up a GitHub Organization takes under 5 minutes and is completely free. There is no valid reason to skip it
— even for a two-person founding team.
■ 2. Free vs Paid Plans — Complete Breakdown
GitHub offers three plan tiers for organizations. As a startup owner you need to know exactly what you get and what you
give up at each level — because these choices directly affect how you build your team and workflows.
Feature Free (■0) Team (~■335/user/mo) Enterprise
(~■1,750/user/mo)
Private repositories Unlimited Unlimited Unlimited
Actions minutes/month 2,000 3,000 50,000
Package & artifact storage 500 MB 2 GB 50 GB
Required PR reviewers ■ No ■ Yes ■ Yes
Branch protection rules Basic Advanced Advanced + bypass
Draft pull requests ■ No ■ Yes ■ Yes
Audit log 90 days, basic Full log Full + streaming
GitHub Pages (private) ■ No ■ Yes ■ Yes
Wikis (private repos) ■ No ■ Yes ■ Yes
SAML / Single Sign-On ■ No ■ No ■ Yes
Secret scanning Public only ■ No ■ Yes (GHAS)
Priority support Community Standard email Premium 24/7
When to Upgrade — A Simple Decision Framework
Team Size & Stage Recommended Plan Key Reason
0–5 people, early stage Free plan Ship fast, validate the idea first
5–15 people, shipping weekly Team plan $20/mo for 5 people — worth it for
required reviewers alone
15+ people or compliance needs Enterprise SAML, advanced security, premium
support
■■ The riskiest Free plan limitation for a growing startup: no required PR reviewers. This means any developer can
push broken code directly to your main branch with no second pair of eyes — this is how production bugs happen.
■ Upgrading Free → Team preserves 100% of your code, repos, members, and teams. Paid features activate
instantly. You can downgrade back to Free anytime — your code is always safe.
■ 3. Adding & Removing Members — The Right Way
■■ Never share your GitHub password or your Gmail with any developer. Every team member creates their own
free GitHub account and you invite their username. That is the only connection — no password sharing, ever.
How to Add a Developer (4 Steps)
Step 1 Developer creates their own free GitHub account at [Link] using any email. Takes 2 minutes.
Their account is theirs — you do not control it or pay for it.
Step 2 You create a Team in your org (e.g., 'Backend Engineers'), assign the relevant repositories to it,
and set the permission level for that team.
Step 3 Go to org → People → Invite member → type their GitHub username. Choose role: Member (for
devs) or Owner (founders/CTO only). They get an email invite valid for 7 days.
Step 4 Add them to the correct Team. They instantly inherit that team's access to all assigned repos — no
per-repo setup needed.
Removing a Developer
Go to org → People → find the person → Remove from organization. All repository access is revoked immediately. Any
code they pushed remains in the org — it belongs to the company, not to them.
■ 4. Access Levels & Permissions
Giving too much access is a security risk. Giving too little is a productivity problem. GitHub has five repository permission
levels — use them precisely.
Level What They Can Do Give To
Read View, clone, download code and files. Read Clients, investors (due diligence), external
issues and PRs. Cannot push any code. auditors, interns in first week
Triage Everything in Read, plus label/assign/close Project managers, scrum masters, product
issues and PRs. Cannot push code. managers
Write Push code, create branches, open PRs, Regular full-time developers — most of your
merge PRs that pass protection rules. engineering team
Cannot change repo settings.
Maintain Everything in Write, plus manage repo Senior engineers and tech leads who own a
settings, branch protection, webhooks. specific service
Admin Full control — delete repo, change all CTO, lead architect only. Maximum 2–3
settings, bypass protection. Most powerful. people. Never give to freelancers.
Organization-Level Roles
Org Role Description & Who Gets It
Member Default role for all employees. Can see the org, be added to teams, access assigned
repos. Cannot see billing or invite others.
Owner Full control: billing, member management, org settings, all repositories. Keep to
founders and CTO only — never more than 3 people. Always maintain at least 2
Owners.
Billing Manager Can only manage billing and view invoices. Cannot see code or manage members.
Ideal for your finance team or accountant.
■ 5. Key Workflows & Common Situations
Q: Can I mix public and private repos?
Yes. Public repos are visible to everyone on the internet. Private repos are only visible to org members explicitly granted
access via a team. A developer in your Backend team will not automatically see repos assigned to other teams.
Q: Can I give a client or investor read-only access?
Yes. Add them as an Outside Collaborator (not a Member) on only the specific repo they need, with Read permission.
They see that repo's code and commits — nothing else in your org. Remove them when the review is done: org →
Settings → Outside collaborators → remove.
Q: We accidentally deleted a repo — is the code gone?
No. GitHub keeps deleted repos for 90 days. Owners: [Link] → Settings → Repositories → Deleted repositories →
Restore. Contact GitHub Support if needed within that window.
Q: A developer pushed broken code to main. How do I fix it fast?
Run: git revert HEAD (or git revert HEAD~3..HEAD for multiple commits), then push. This creates a new commit that
undoes the damage without deleting history. Long-term fix: enable branch protection so all changes must go through a
PR with reviewer approval.
Q: What if we stop paying — is our code deleted?
No. If a payment fails or you downgrade, GitHub moves your org back to the Free plan. All repos, code, members, and
history remain 100% intact. The only way repos are deleted is if an Owner manually deletes them — and even then,
GitHub keeps them recoverable for 90 days.
Q: Our GitHub Actions stopped mid-month — deployment is broken.
You hit the 2,000 free minutes/month limit. Fix: upgrade to Team plan (pipelines resume instantly), wait for billing cycle
reset, or buy extra minutes. Prevent it: set a spending limit with email alerts in org → Settings → Billing.
■ 6. Security Best Practices
Most startup security incidents involving code repositories are not the result of sophisticated attacks — they are the result
of poor access management. The following practices eliminate the most common risks.
Security Practice What to Do
Enable 2FA for all Owners Make it mandatory in org Settings → Authentication security.
Non-negotiable.
Least-privilege access Give developers access only to repos they actively need — nothing
more.
Branch protection on main Require a PR with at least 1 reviewer approval before any merge. No
direct pushes.
Remove access immediately On a developer's last day — before any exit conversation if possible.
Outside Collaborators for freelancers Never add freelancers as full Members. Limit them to specific repos
only.
Separate team for sensitive repos Infrastructure and production config repos: Write access for senior
engineers only.
Audit access every 6 months Review org → People and each Team. Remove stale access. Takes
about 2 hours.
Maintain at least 2 Owners If the only Owner's account is compromised, regaining control can take
days.
■■ Anyone with repository access can clone private code to their local machine — you cannot delete it remotely
once cloned. Strict access controls and NDAs are your primary safeguards.
■ 7. Setup Checklist — Do This Today
Follow these steps in order when setting up your GitHub Organization. Each item takes only a few minutes and pays
dividends for years. Tick each one off before inviting your first developer.
✓ Action How / Detail
■ Create a company email admin@[Link] — not a personal Gmail. Use
Google Workspace or any business email.
■ Create the GitHub Use the official startup name. Set billing to the company email,
Organization not your personal one.
■ Add co-founders as Owners Go to org → People → Invite → set role to Owner. Always keep
at least 2 Owners active.
■ Create your Team structure Backend / Frontend / DevOps / QA / Interns — create all teams
before inviting anyone.
■ Invite developers by username They use their own GitHub accounts. You invite their username.
Zero password sharing.
■ Enable branch protection on Require PRs + at least 1 reviewer approval. No direct pushes to
main main, ever.
■ Enforce 2FA for Owners org → Settings → Authentication security → require 2FA.
■ Create all repos inside the org Never in personal accounts. Every repo must live at
[Link]/your-org/repo-name.
■ Document your access policy Write down who gets what role and why. Share with your CTO
or tech lead.
■ Schedule 6-month access Put a recurring calendar reminder. People change roles;
reviews contractors and interns leave.
■■ The single biggest mistake startups make: keeping all code in a founder's personal GitHub account. 18 months
later — 8 developers, 30 repos, an investor asking for due diligence — migrating everything is painful and raises
immediate red flags. A GitHub Organization takes 5 minutes to set up, costs nothing on the Free plan, and protects
everything from day one. There is no valid reason to skip it.