GitHub Repo Ownership & Access (Beginner, No Terminal)
Understand where your website repo lives, how you get access, and how we transfer it to you any time.
Git is our source of truth: it keeps your site portable, recoverable, and easy to hand off when volunteers change.
By default, we may host the repo in the 4leggedIT GitHub organization during active development.
You can request a transfer to your GitHub account or your GitHub organization any time.
Quick Path
- Default: repo hosted in 4leggedIT’s GitHub org during development; you get access to it.
- Optional: host the repo in your GitHub org/account from the start (recommended for long-term ownership).
- Transfer the repo to you any time; the full commit history transfers with it.
- If you deploy with Cloudflare Pages, you may need to reconnect the repo after transfer.
- Protect against turnover: 2+ owners, 2FA, and saved recovery codes.
Step 1 — Choose where the repository lives
This is the “who hosts the repo” decision.
Both options still use GitHub, and both keep you portable. The main difference is who is the repo owner today.
- Choose one:
- Option A (common during build): repo lives in the 4leggedIT GitHub organization.
- Option B (recommended long-term): repo lives in your GitHub organization or account.
- If you don’t already have a GitHub account, create one first (personal is fine). Later, you can create a GitHub Organization for your rescue.
- If you want Option B, tell us your GitHub username (and org name if you have one) so we can set it up correctly.
You know where the repo will live today.
You know you can transfer ownership later with full history.
Step 2 — Get access to the repo (no terminal required)
This step makes sure you can see the code and keep it safe.
We recommend at least two trusted people have access (so you’re not blocked if someone is unavailable).
- Create (or confirm) your GitHub account.
- Send us the GitHub username(s) that should have access (example: board member + operations lead).
- Accept the GitHub invitation(s) you receive by email or in GitHub notifications.
- Confirm you can open the repo in a browser and see files like package.json.
- If you can’t access it, don’t “work around” by creating a new repo—tell us and we’ll fix permissions.
You can view the repo in GitHub, and you have at least one backup admin/owner on your side.
Step 3 — Transfer the repo to your GitHub (any time)
This step moves repository ownership from one GitHub owner to another.
The key promise: you can request a transfer to your GitHub account or organization any time.
- Decide the destination owner: your personal GitHub account or your rescue’s GitHub Organization.
- Tell us the exact destination owner name in GitHub.
- We initiate the transfer in GitHub, then GitHub sends an acceptance request to the destination owner.
- The destination owner accepts the transfer in GitHub.
- Confirm the repo now appears under the new owner and your team still has access.
The repo is owned by your GitHub account/org.
The full commit history is intact.
Step 4 — Reconnect deployment (if you use Cloudflare Pages or other integrations)
Some integrations “remember” the old repo location.
After a transfer, you may need a quick reconnect so deploys keep working.
- If you use Cloudflare Pages, open your Pages project and confirm it still points to the correct GitHub repo.
- If Cloudflare asks you to reconnect or re-authorize GitHub, follow the prompts.
- Trigger a small change (like a one-line text edit) and confirm a new deployment occurs.
- If you’re unsure which deploy method you’re using, start with Publish With Cloudflare Pages + GitHub.
Deploys still run successfully after the transfer.
Step 5 — Ownership safety checklist (protect against turnover)
This step prevents the most common “we’re locked out” failure modes.
These are simple, high-impact controls for volunteer-run teams.
- Ensure at least two trusted people can administer the repo (owners/admins).
- Turn on two-factor authentication (2FA) for those accounts.
- Save recovery codes somewhere your organization can access (not in a single person’s email).
- Keep a simple “access roster”: who has access, what role they have, and when it was last reviewed.
- If you use a GitHub Organization, consider enforcing 2FA for the org and keeping a documented process for adding/removing admins.
If someone leaves, your organization can still access and operate the website repo.
Official References
Open these only if something doesn’t match your screen.
You do not need to read them to complete the guide.
Related How-To Sessions
Want us to set up access safely?
Tell us who should have GitHub access (and whether you want the repo under your GitHub now or later). We’ll set it up with least-privilege and clear handoff.