👥 Team Workflows

🌊 GitHub Flow

GitHub Flow has one long-lived branch, main, which is always working and always deployable. Every change, however small, happens on a short-lived branch and reaches main through a pull request.

1. Start from an up-to-date main: git switch main, git pull.
2. Branch with a descriptive name: git switch -c add-gallery.
3. Commit in small steps and push the branch early: git push -u origin add-gallery.
4. Open a pull request as soon as you want feedback. It can be a draft.
5. Review and check: teammates comment, the Netlify Deploy Preview shows the real result, automated checks run.
6. Merge, then delete the branch. Netlify deploys main. Everyone runs git switch main + git pull before their next branch.

🤝 Collaborators & Forks

Organizations (free for public work) let a group own repositories together and manage people in teams. Useful once you have more than a couple of shared repos.

🛡️ Protecting main

"Main is always deployable" is easier to keep when GitHub enforces it. Go to Settings → Rules → Rulesets → New ruleset → New branch ruleset (older repositories may show Settings → Branches → Add branch protection rule instead), target the default branch, and turn on:

• Require a pull request before merging: nobody, including you, can push straight to main. Optionally require one or more approvals.
• Require status checks to pass: the PR can't be merged until checks (like the HTML check below, or the Netlify deploy) are green.
• Block force pushes: history on main can't be rewritten.

On GitHub's free plan these rules apply to public repositories; enforcing them on private repositories needs a paid plan. Wording and menus move occasionally, so if a label differs, look for "Rules" or "Branches" in Settings.

🔍 Pull Requests & Code Review

Writing a PR people want to review

• A clear title in the same style as a commit message: "Add photo gallery page".
• What and why in a few sentences. Screenshots or the Deploy Preview link help a lot for visual changes.
• How to check it: "Open /gallery.html on the preview and resize to phone width."
• Link the issue: writing Closes #12 in the description closes issue 12 automatically when the PR is merged into main.
• Keep it small. A PR that does one thing gets a thoughtful review in minutes; a 40-file PR gets "looks good 👍" and hidden bugs.

Reviewing

Open the Files changed tab. Click the + beside any line to comment on it, or select several lines. When you're done, click Review changes (the label may read "Submit review") and choose Comment, Approve, or Request changes. The author answers by pushing new commits to the same branch; the PR updates itself.

The three merge buttons

Teams usually pick one and stick to it. After a squash merge, delete your local branch with git branch -D, because Git can't tell it was merged (the commits on main are different ones).

🔄 Staying in Sync

Most team friction comes from working on an out-of-date copy. Three habits prevent nearly all of it:

1. Pull before you branch. Always git switch main + git pull first.
2. Keep branches short-lived. A branch merged within a day or two rarely conflicts; one left open for a month almost always does.
3. Bring main into a long-running branch when main has moved on, so you deal with conflicts early and on your own terms:

git switch main
git pull
git switch add-gallery
git merge main
# resolve any conflicts, commit, then:
git push

GitHub offers the same thing as an Update branch button on the pull request when main has moved ahead.

📏 Conventions

Commit messages

Everything from class still applies: imperative mood, say what and why, one change per commit. Some teams add a structured prefix called Conventional Commits so tools can build changelogs automatically:

<type>(<optional scope>): <short summary>

<optional body: what changed and why>

<optional footer, e.g. Closes #12>

feat(gallery): add lightbox to photo grid
fix(nav): correct link to contact page
docs: explain local setup in README
style(css): reformat colors section
chore: remove unused images

Common types are feat (a new feature), fix (a bug fix), docs, style (formatting only), refactor, test, and chore. Use this only if your team agrees to. A plain, clear message is always fine.

Branch names

Lowercase, hyphens instead of spaces, and short enough to type. The prefix is optional; consistency is what matters.

Shared shortcuts (aliases)

git config --global alias.st "status"
git config --global alias.lg "log --oneline --graph --all"
git config --global alias.last "log -1 --stat"

Now git lg draws the branch graph and git last summarizes your latest commit. Aliases live in your own config, so teammates each set up their own.

🤖 Automated Checks (GitHub Actions)

Continuous integration (CI) means a robot runs checks on every push and pull request, so problems show up before they reach main. Your Netlify Deploy Preview is already a simple version: if the build fails, the PR shows a red ✗. GitHub Actions lets you add your own checks with a small YAML file in the repository.

For example, to check every HTML page for mistakes (unclosed tags, missing alt text, duplicate IDs), create .github/workflows/check-html.yml in VS Code:

name: Check HTML

on:
  pull_request:
  push:
    branches: [main]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "lts/*"
      - run: npx --yes html-validate "**/*.html"

and a .htmlvalidate.json in the repository root that picks the rule set:

{
  "extends": ["html-validate:recommended"]
}

Commit both files and open a pull request. A Checks section appears on the PR, and the Actions tab shows every run with its log. The recommended rules are strict; if they flag things you're happy with, the html-validate documentation explains how to switch individual rules off.

🗺️ Other Branching Models

You'll read about other workflows online. They're answers to different problems, not "more advanced" versions of GitHub Flow.

Git Flow

Designed for software shipped in numbered releases (desktop apps, libraries). Work happens on develop; release/* branches stabilize a version; main only receives finished releases (tagged v1.1, v1.2…); urgent hotfix/* branches start from main and merge back into both.

Trunk-based development

Everyone merges tiny changes into main (the "trunk") at least daily, relying heavily on automated tests and "feature flags" to hide unfinished work. Common at large tech companies.

For a website deployed by Netlify, GitHub Flow is almost always the right choice.

🔐 Secrets & Security

Keep secrets out of Git

Anything pushed to a public repository can be copied within minutes, and even deleting it later doesn't remove it from history or from other people's clones. API keys, passwords, and tokens belong in environment variables (Netlify has Site configuration → Environment variables) and in files listed in .gitignore:

# .gitignore
.env
.env.*
*.pem
*.key

GitHub's push protection blocks pushes that contain many well-known kinds of secret, and it's on by default for public repositories. Treat it as a seatbelt, not a plan.

Accounts

• Turn on two-factor authentication (GitHub requires it for most people who contribute code).
• Use HTTPS with Git Credential Manager or gh auth login, as in Lesson 5. If you ever create a personal access token, give it the smallest permissions and an expiry date.
• Review Settings → Collaborators now and then and remove people who no longer need access.

Signed commits (optional)

Anyone can put any name in user.name. Signing proves a commit really came from you, and GitHub shows a Verified badge. (Commits you make in GitHub's web editor are signed automatically.) The simplest method uses an SSH key:

ssh-keygen -t ed25519 -C "you@example.com"
git config --global gpg.format ssh
git config --global user.signingkey /path/to/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Replace the path with where ssh-keygen saved your key (it tells you). Then on GitHub go to Settings → SSH and GPG keys → New SSH key, choose Key type: Signing Key, and paste the contents of the .pub file. GitHub's "Signing commits" documentation covers GPG keys as well.

🩺 Team Troubleshooting