Collaborating on GitHub Pages

The collaboration model

1. One person creates the repo — under their personal account to start, or directly under a GitHub organisation (recommended for team work).
2. GitHub Pages is enabled — deploy from the main branch, root directory (/). This means every file at the top level of the repo is served as a webpage. Every merge to main triggers a publish automatically.
3. Team members are added with appropriate roles — Write for contributors, Maintain for whoever is responsible for merging.
4. Branch protection is turned on — no direct pushes to main, pull requests required, at least one review before merge.
5. Each person (or their agentic app) works in a named branch — drafts and commits stay isolated until a pull request is raised.
6. A human reviews and merges the pull request — the final checkpoint before anything goes live.

Org-owned repos vs personal repos

When you first create a GitHub repo it defaults to your personal account. That's fine for solo work, but for anything the team owns together, an org-owned repo is the right choice.

Creating a repo under a GitHub organisation

You can ask your agentic app to walk you through this. Try: "Help me create a new repository under my GitHub organisation on github.com and enable GitHub Pages." It will guide you through each step or do it via the GitHub API if it has access.

Adding members and setting roles

There are two ways to give someone access to an org repo: add them as an org member (access across all org repos) or as an outside collaborator on a specific repo (recommended for people outside your immediate team).

Within a repo, each person gets one of five roles:

How to add a collaborator

Governance — who controls what gets published

The most important governance decision: no one pushes directly to main. Every change goes through a pull request. This applies equally to humans and to agentic apps acting on their behalf.

Setting up branch protection on main

1. Go to Settings → Branches → Add branch protection rule.
2. Set the branch name pattern to main.
3. Enable Require a pull request before merging. Set Required approvals to 1.
4. Enable Do not allow bypassing the above settings — prevents admins from pushing around the rules.
5. Save. Nobody — human or agentic app — can push directly to main.

CODEOWNERS — auto-assign reviewers by section

As the site grows, different people own different pages. A CODEOWNERS file tells GitHub who to automatically request a review from when a particular file changes — no one has to remember to tag anyone.

Your agentic app can create and maintain this file for you. Just say: "Create a CODEOWNERS file so that changes to mcps-read.html require a review from @colleague-username, and everything else defaults to me." The file lives at .github/CODEOWNERS and looks like this:

# Default owner for all files
*                  @your-username

# A colleague owns the MCPs section
mcps-read.html     @colleague-username
mcp-setup.html    @colleague-username

When a pull request touches mcps-read.html, GitHub automatically adds the colleague as a required reviewer. You never need to edit this file manually — ask your agentic app to update it whenever ownership changes.

Contributing without HTML knowledge

Contributors don't need to touch HTML. Their agentic app handles file editing — they just describe what they want.

Step-by-step: adding content to the site

1. Open the repo in your agentic app — most agentic apps (including desktop-based ones) let you open a folder from a cloned repo, or can connect directly to a GitHub repo URL. Ask your agentic app: "How do I open a GitHub repo so you can edit files in it?" for the right steps in your specific tool.
2. Ask your agentic app to create a branch — start every session with: "Create a new branch called feature/your-name-topic and switch to it."
3. Describe the content you want — e.g. "Add a new section to skills.html explaining how to use Skills to wrap Webex workflows. Match the existing style."
4. Review the result — open the file in a browser locally to check it looks right before committing.
5. Ask your agentic app to commit and push — "Commit these changes with a short message and push to origin."
6. Open a pull request — go to the repo on GitHub. It will prompt you to create a pull request from your new branch. Add a short description of what you changed.
7. Wait for review and merge — the maintainer reviews and merges. The site updates within ~60 seconds.

Agentic collaboration conflicts

What happens when two people using an agentic app try to update the same site at the same time? Unlike Google Docs, there's no real-time presence indicator. Here's what actually happens — and how branch protection prevents problems.

Without branch protection: direct pushes to main

With branch protection: each session in its own branch

Both pull requests exist simultaneously. A human reviews each one and merges in sequence. Both sets of changes land on main cleanly. No conflict. No override.

The only time a conflict surfaces is if both sessions edited the same lines in the same file. In that case, GitHub shows a merge conflict warning on the pull request before merge — making it visible and requiring a human to resolve it before anything goes live.

Who has final say?

With branch protection enabled: the person who clicks Merge on the pull request. No agentic tool can deploy to the live site unilaterally — the deploy gate is always a human action.

Best practices to prevent conflicts

Questions or edge cases not covered here? , or ask your agentic app to help you think through your specific situation.