# GitHub

## What GitHub is (context)
- Largest host for Git repositories
- Central collaboration hub for millions of developers and projects
- Commonly used for
  - Git hosting
  - Issue tracking
  - Code review
  - Other collaboration features
- Not part of the Git open source project itself
  - But very likely you’ll need to interact with it professionally

## Chapter scope (what you’ll learn)
- Use GitHub effectively:
  - Sign up for and manage an account
  - Create and use Git repositories on GitHub
  - Contribute to other projects (and accept contributions to yours)
  - Use GitHub’s programmatic interface (API)
  - Tips and small features that make workflows easier
- If you don’t plan to use GitHub for hosting/collaboration
  - You can skip ahead to **Git Tools**

## Note: Interfaces change (UI disclaimer)
- GitHub UI and screenshots change over time
- The *concepts* should remain applicable
- Online versions of the book may have newer screenshots

---

## Account Setup and Configuration

### Create a free account (sign-up)
- Go to: `https://github.com`
- Fill in:
  - Username (must be unique)
  - Email address
  - Password
- Click **“Sign up for GitHub”** (green button)
- You may see an upgrades/pricing page next
  - Safe to ignore initially
- Verify your email address (GitHub sends a verification email)
  - Important for later steps/workflows
- Account capabilities & plans
  - Free accounts provide almost all functionality
  - Paid plans: advanced tools/features + increased limits
  - More info: `https://github.com/pricing`
- Navigation
  - Clicking the **Octocat** logo (top-left) takes you to your dashboard

### SSH Access (HTTPS vs SSH)
- HTTPS remotes
  - You can connect to Git repos over HTTPS using username/password
  - Cloning public projects doesn’t require an account
  - Account becomes important for:
    - forking projects
    - pushing to your fork
- SSH remotes
  - Requires configuring an SSH public key
  - If you don’t have a key yet: generate one (referenced elsewhere in the book)

#### Add an SSH key to your GitHub account
- Open **Account settings** (link at the top-right)
- Select **“SSH keys”** in the left sidebar
- Click **“Add an SSH key”**
- Provide:
  - A recognizable **title/name** for the key (helps later revocation)
    - Example naming patterns: “My Laptop”, “Work Account”
  - Paste the contents of your public key file (e.g. `~/.ssh/id_rsa.pub`)
- Click **“Add key”**

### Your Avatar (profile picture)
- Optional customization
- Steps
  - Go to **Profile** tab (in account settings)
  - Click **“Upload new picture”**
  - Select an image
  - Crop it
- Effect
  - Your avatar appears next to your username everywhere you interact on GitHub
- Gravatar integration
  - If you already have a Gravatar avatar, GitHub may use it by default

### Your Email Addresses (commit ↔ account mapping)
- How GitHub associates commits with your account
  - By **email address** in commits
- If you commit with multiple emails
  - Add all of them in the **Emails** section in settings
- Email address states (as shown in the example)
  - Verified + Primary
    - Receives notifications/receipts
  - Verified (non-primary)
    - Can be promoted to primary
  - Unverified
    - Cannot be primary
- Once added
  - Any commit on GitHub using one of these emails will link to your user

### Two-Factor Authentication (2FA)
- Purpose
  - Extra security
  - Reduces impact if password is stolen/compromised
- Location
  - **Security** tab in account settings
- Setup
  - Click **“Set up two-factor authentication”**
  - Choose a second factor method:
    - Phone app generating a **time-based one-time password (TOTP)**
    - SMS code sent each login
- After enabling
  - GitHub requires password + code on login

---

## Contributing to a Project

### Forking Projects (contribute without push access)
- Problem: you want to contribute but you can’t push to the upstream repo
- Solution: **Fork**
  - GitHub creates a full copy of the repo under your namespace
  - You can push to your fork
- Terminology note (historical vs GitHub meaning)
  - Historically “fork” could imply a split/competing direction
  - On GitHub: “fork” generally means “same project under your account to propose changes”
- Why this works well
  - Upstream maintainers don’t need to add you as a collaborator
  - You propose changes via a **Pull Request (PR)**
  - PR becomes a discussion + review thread
  - Maintainer merges when satisfied
- How to fork
  - Visit the project page
  - Click **“Fork”** (top-right)
  - GitHub redirects you to your forked repo page

### The GitHub Flow (PR-centered collaboration model)
- Works for:
  - Small teams sharing a repo
  - Large distributed groups and many forks
- Built around **Topic Branches** (as covered in Git Branching)
- Typical sequence
  1. Fork the project
  2. Create a topic branch from `master`
  3. Commit improvements
  4. Push the topic branch to your GitHub fork
  5. Open a Pull Request
  6. Discuss; optionally keep committing to the same branch
  7. Owner merges or closes the PR
  8. Sync upstream changes back into your fork
- Related concept
  - Similar to the **Integration Manager** workflow, but discussion/review is web-based rather than email-based
- Alternative tooling tip
  - GitHub CLI can do most web-interface tasks
  - Runs on Windows, macOS, Linux (installation/manual referenced in chapter)

---

## Creating a Pull Request (walkthrough example)

### Scenario
- Tony wants Arduino code and finds: `https://github.com/schacon/blink`
- Problem
  - Blink delay is too fast
- Goal
  - Change delay from 1 second to 3 seconds
  - Submit improvement via PR

### Local workflow steps (fork → branch → change → push)
- Fork upstream repo (`schacon/blink`) to your namespace
  - Example fork URL: `https://github.com/tonychacon/blink`
- Clone your fork locally
  - `git clone https://github.com/tonychacon/blink`
- Create a descriptive topic branch
  - `git checkout -b slow-blink`
- Make the code change (example uses `sed`)
  - macOS:
    - `sed -i '' 's/1000/3000/' blink.ino`
  - Linux:
    - `sed -i 's/1000/3000/' blink.ino`
- Review the change
  - `git diff --word-diff`
- Commit
  - `git commit -a -m 'Change delay to 3 seconds'`
- Push the topic branch to your fork
  - `git push origin slow-blink`
  - If using HTTPS remote, you may be prompted for GitHub username/password

#### Meaning of the numbered actions (as presented in the example)
- ① clone fork locally
- ② create topic branch
- ③ edit code
- ④ verify diff
- ⑤ commit to topic branch
- ⑥ push topic branch to GitHub fork

### Open the Pull Request on GitHub
- GitHub notices the new branch on your fork and suggests creating a PR (green button)
- Alternative path
  - Use the Branches page:
    - `https://github.com/<user>/<project>/branches`
- PR creation page typically shows
  - Title + description fields (recommended to write clearly)
  - Commits “ahead” of `master`
  - Unified diff of all changes that would be merged
- After clicking **Create pull request**
  - The upstream maintainer is notified
  - They can review and respond

### PRs can be opened early (not only “final” work)
- Common in internal/team settings
- Because you can keep pushing commits to the PR branch after opening the PR
- PR becomes a shared context for iterative development and review

---

## Iterating on a Pull Request (review + updates)

### How review happens on GitHub
- Maintainer can:
  - merge
  - reject/close
  - comment (line-level or general)
- Line-level comments
  - Maintainer comments by clicking specific lines in the diff
- General comments
  - In the PR discussion thread
  - Line comments are also pulled into the overall conversation

### Notifications during PR discussion
- PR author and watchers get notified on comments/activity
- If email notifications are enabled
  - Comments may arrive as emails

### Updating an existing PR
- GitHub workflow approach
  - Don’t “re-roll” patches like mailing lists
  - Instead:
    - add commits to the same topic branch
    - push again
    - PR updates automatically
- Old line comments may collapse when code changes (they become “outdated”)
- Note about notifications
  - Adding commits to an open PR does **not** necessarily trigger a notification
  - Contributors often add a comment saying they pushed updates

### “Files Changed” tab meaning (unified diff)
- Shows total aggregate difference introduced by merging the PR branch
- Equivalent to:
  - `git diff master...<branch>` (three-dot diff) for the PR base

### Merging the PR (server-side vs local)
- GitHub checks if PR merges cleanly
- If you have write access and merge is trivial
  - GitHub shows a merge button
  - Clicking it performs a **non-fast-forward merge**
    - Creates a merge commit even if fast-forward was possible
- Alternative
  - Pull the PR branch and merge locally
  - If you push the merge to GitHub, the PR closes automatically

### Not only forks (internal PRs)
- You can open PRs between branches in the same repository
- Useful when:
  - multiple collaborators with write access
  - you want structured review/discussion without forking

---

## Advanced Pull Requests

### Pull Requests as iterative conversations (vs “perfect patch queues”)
- Many GitHub projects view PRs as:
  - a branch where the change evolves through discussion
  - culminating in the final unified diff applied via merge
- Contrast with mailing-list patch series
  - Mailing lists often expect a clean sequence of patches
  - GitHub supports earlier engagement and incremental improvements
- Practical implication
  - Contributors frequently add commits instead of rebasing/resubmitting PRs
  - Merge commits created by GitHub can reference the PR for traceability

---

## Keeping up with upstream (fixing out-of-date/conflicting PR branches)

### When you need this
- PR becomes out of date
- GitHub reports: PR “does not merge cleanly”
- Goal
  - Make PR mergeable (green) so maintainers don’t have extra work

### Two main strategies
- Rebase onto upstream target branch (usually upstream `master`)
- Merge upstream target branch into your topic branch
  - Common preference on GitHub:
    - preserves history/context
    - simpler/less error-prone than rebasing for many teams

### Merge upstream into your topic branch (step-by-step)
- Add upstream repo as remote
  - `git remote add upstream https://github.com/schacon/blink`
- Fetch upstream
  - `git fetch upstream`
- Merge upstream main branch into your topic branch
  - `git merge upstream/master`
- Resolve conflicts (if any)
  - edit conflicting files (example: `blink.ino`)
  - `git add <file>`
  - `git commit` (records the merge)
- Push updated topic branch back to your fork/branch
  - `git push origin slow-blink`
- Result
  - GitHub updates PR and re-checks mergeability automatically

### Long-running work
- You can repeat “merge from upstream” regularly
- Conflicts are limited to changes since your last merge

### Rebasing caution (especially once PR is open)
- If you rebase and force-push over the branch used by an open PR
  - it can disrupt collaborators who fetched the branch
  - it can trigger the issues described in “Perils of Rebasing” (referenced)
- Recommended alternative if you want a clean rebased history
  - push rebased commits to a **new** branch
  - open a **new** PR referencing the old PR
  - close the original PR

---

## References (cross-linking Issues, PRs, commits)

### Issue/PR number references (within a repository)
- Every Issue and PR has a unique number within a project
- Quick reference syntax
  - `#<num>` in comments/descriptions links automatically

### Cross-repo / cross-fork references
- In a fork of the repo you’re in:
  - `username#<num>`
- In a different repository:
  - `username/repo#<num>`
- Full GitHub URLs can also be pasted
  - GitHub renders them as shortened references

### Trackbacks
- Mentioning a PR in another PR can create timeline cross-links
  - Helps connect superseding PRs when one is closed

### Commit references
- You can reference a commit by SHA-1
- Requirement in chapter
  - must use the **full 40-character SHA-1** for auto-linking
- Same cross-repo patterns apply (similar to issue references)

---

## GitHub Flavored Markdown (GFM)

### Where it works
- PR descriptions
- Issue descriptions
- Comments
- Code comments
- Many GitHub text boxes

### What it is
- Markdown: plain text that renders richly
- GitHub adds extensions beyond base Markdown

### Task Lists
- Purpose
  - Checklist of work items (often “before merge/complete” items)
- Syntax
  - `- [X]` checked
  - `- [ ]` unchecked
- Convenience
  - Checkboxes can be clicked directly (no need to edit Markdown)
- Visibility
  - GitHub summarizes task progress on PR/Issue list pages
- Common usage pattern
  - Open PR early, track progress via tasks

### Code Snippets (fenced code blocks)
- Use cases
  - propose code ideas before committing
  - share failing examples
  - demonstrate intended behavior
- Syntax
  - Fence with triple backticks
  - Add a language name for syntax highlighting (example: `java`)

### Quoting
- Quote lines by prefixing with `>`
- Shortcut
  - Select text in a comment and press `r` to quote it in the reply box

### Emoji
- Emoji helper/autocomplete appears when typing `:`
- Syntax
  - `:<name>:` (e.g., `:+1:`)
- Comment tone
  - Adds emotion/fun; not essential but commonly used
- Emoji cheat sheet link provided
  - `https://www.webfx.com/tools/emoji-cheat-sheet/`

### Images (drag & drop)
- Not strictly a “GFM extension,” but supported
- Easier than manually creating Markdown image links
- Drag and drop images into comment text areas
  - GitHub uploads and auto-embeds
- “Parsed as Markdown” hint
  - Provides a cheat sheet of supported Markdown features

---

## Keep your GitHub public fork up-to-date (syncing your fork’s `master`)

### Key point
- A fork is independent of the original repo
- GitHub may show “X commits behind upstream”
- GitHub will not automatically update your fork

### Simple method (no extra configuration)
- `git checkout master`
- `git pull https://github.com/progit/progit2.git`
  - fetch + merge into your `master`
- `git push origin master`
  - update your fork on GitHub
- Downside
  - Typing the upstream URL repeatedly is tedious

### Configured method (more convenient)
- Add upstream remote
  - `git remote add progit https://github.com/progit/progit2.git`
- Fetch upstream
  - `git fetch progit`
- Set your local `master` to pull from upstream `master`
  - `git branch --set-upstream-to=progit/master master`
- Set default push destination to your fork
  - `git config --local remote.pushDefault origin`
- Then the routine becomes
  - `git checkout master`
  - `git pull`
  - `git push`

### Important caution
- With this setup Git won’t warn if you:
  - commit to `master`
  - pull from upstream
  - push to origin
- You must treat `master` as “belonging to upstream”
  - avoid committing directly to `master`

---

## Maintaining a Project

## Creating a New Repository
- Entry points
  - “New repository” button on dashboard
  - `+` menu in top toolbar → “New repository”
- New repository form
  - Required: repository/project name
  - All other fields optional
- After creation
  - Repo available as `<user>/<project_name>`
  - If empty, GitHub provides instructions to:
    - create a new repo locally and push
    - connect an existing repo
  - (Refresher referenced: Git Basics)
- Repo URLs
  - HTTPS: `https://github.com/<user>/<project_name>`
  - SSH: `git@github.com:<user>/<project_name>`
- Sharing tip (public projects)
  - Prefer sharing HTTPS URL
    - cloning doesn’t require a GitHub account
  - SSH requires account + SSH key

## Adding Collaborators
- Purpose
  - Grant push access (read + write)
- Steps
  - Repo page → **Settings**
  - Left menu → **Collaborators**
  - Add by username → “Add collaborator”
  - Remove access by clicking “X” next to collaborator

---

## Managing Pull Requests (as a maintainer)

### Where PRs come from
- Fork-based PRs
  - contributor’s branch in their fork
  - usually you cannot push to their branch
- Internal PRs (same repo)
  - branches inside your repo
  - typically both sides can push to the branch

### Email notifications (new PR)
- Maintainer receives email for a new PR
- Email includes
  - Diffstat (files changed and how much)
  - Link to the PR on GitHub
  - Useful command-line URLs/commands
    - `git pull <url> patch-1` (merge remote branch without adding remote)
    - `.diff` and `.patch` links for PR content
      - Example patch application:
        - `curl https://github.com/<user>/<repo>/pull/<id>.patch | git am`

### Collaborating on the PR (discussion + review)
- You can comment on
  - specific lines
  - whole commits
  - general PR discussion
- Uses GitHub Flavored Markdown everywhere
- Email replies can be included back into the GitHub thread (metadata supports this)

### Merging or closing
- Merge locally (various ways)
  - `git pull <url> <branch>`
  - or add remote for the fork, fetch, then merge
- Merge on GitHub site
  - If merge is trivial, use **Merge** button
  - Creates **non-fast-forward** merge commit even if fast-forward is possible
- If you decide not to merge
  - Close the PR
  - Author is notified

---

## Pull Request Refs (advanced: fetching PRs like branches)

### Motivation
- Many PRs → avoid:
  - adding numerous remotes
  - repeating one-off `git pull <url>` operations

### Key idea
- GitHub exposes PRs as “pseudo-branches”
- They exist under:
  - `refs/pull/…`
- Not fetched by default because normal fetch refspec targets:
  - `refs/heads/*`

### Discover PR refs on the remote
- Use plumbing command:
  - `git ls-remote <repo-url>`
- You’ll see entries like:
  - `refs/heads/master`
  - `refs/pull/<id>/head`
  - `refs/pull/<id>/merge`

### Two refs per PR (what they mean)
- `refs/pull/<id>/head`
  - points to the tip commit of the PR branch
- `refs/pull/<id>/merge`
  - points to the merge commit GitHub would create when using the merge button
  - useful for testing the would-be merge result

### Fetch a single PR head ref directly
- Example
  - `git fetch origin refs/pull/958/head`
- Result
  - stored in `.git/FETCH_HEAD`
- Downsides
  - repetitive for many PRs
  - merging `FETCH_HEAD` can produce awkward merge messages

### Fetch all PR heads automatically via refspec
- Edit `.git/config` and add a second `fetch =` line under the `origin` remote:
  - Existing (typical):
    - `fetch = +refs/heads/*:refs/remotes/origin/*`
  - Add:
    - `fetch = +refs/pull/*/head:refs/remotes/origin/pr/*`
- After `git fetch`
  - PRs appear locally as:
    - `origin/pr/<id>`
- You can test a PR locally
  - `git checkout pr/2`
  - Creates a local branch tracking the fetched PR ref
- Note in chapter
  - The `/head` suffix is intentional; GitHub also provides `/merge` refs

---

## Pull Requests on Pull Requests
- PR target is not limited to `master`
- You can target
  - any branch in the network
  - even another Pull Request branch
- Why this is useful
  - proposed change depends on another PR
  - exploratory/uncertain change
  - you don’t have push access to the target branch
- How to do it (PR creation UI)
  - edit the base/compare selection
  - can change both:
    - branches
    - forks (where the branches live)

---

## Mentions and Notifications

### @mentions
- Type `@` in a comment to autocomplete:
  - collaborators
  - contributors
- Can mention users not in the dropdown too

### Notification effects
- Mentioned user is notified
- Mentioned user becomes subscribed (keeps receiving updates)
- You are also subscribed if you:
  - open the Issue/PR
  - watch the repo
  - comment on the thread

### Unsubscribe
- Use **Unsubscribe** button on Issue/PR page to stop updates

---

## The Notifications Page (config + handling)

### Where to configure
- Settings → **Notification center**
- Two delivery channels
  - Email
  - Web
- Each can be toggled separately for:
  - **Participating** (threads you engage in / @mentioned)
  - **Watching** (repos you watch)

### Web notifications
- GitHub-only
- Indicated by a blue dot on the notifications icon
- Notification center features
  - grouped by project
  - filter by project (left sidebar)
  - mark read individually (checkmark)
  - mark all in project read
  - mute an item (stop future notifications)

### Email notifications
- Emails are threaded in many email clients
- Headers include metadata useful for filtering/rules, such as:
  - `Message-ID` encoding: `<user>/<project>/<type>/<id>`
    - `<type>` differs for issues vs pull requests
  - List-style headers:
    - `List-Post`
    - `List-Unsubscribe`
    - `List-Archive`
- Mail clients can use these headers to:
  - reply-post into the thread
  - unsubscribe/mute via email
- Read synchronization
  - if both web + email are enabled:
    - reading the email can mark the web notification as read (when images are allowed)

---

## Special Files GitHub Recognizes

### README
- GitHub renders a README on the project landing page
- Recognized formats include:
  - `README`
  - `README.md`
  - `README.asciidoc`
  - etc.
- Common README contents
  - project purpose
  - install/config instructions
  - usage/running example
  - license
  - contribution guidance
- Because GitHub renders it, you can include
  - images
  - links

### CONTRIBUTING
- A `CONTRIBUTING` file (any extension) triggers GitHub to show contribution guidelines when opening a PR
- Purpose
  - define what you want/don’t want in PR submissions
  - increase chance contributors read guidelines before submitting

---

## Project Administration

### Changing the default branch
- If you want a default branch other than `master`
  - affects what users see by default
  - affects PR defaults
  - affects default branch checked out on clone
- Location
  - Repo settings → **Options** → Default branch dropdown

### Transferring a project (ownership transfer)
- Repo settings → **Options** → “Transfer ownership”
- Transfer to:
  - another user
  - an organization
- Useful for:
  - handing off a project you no longer maintain
  - moving a growing project into an organization
- Effects
  - moves repo with watchers and stars
  - creates redirects for:
    - web URLs
    - Git clone/fetch URLs (not only web)

---

## Managing an Organization

## Organization basics
- Organizations have:
  - shared namespace for projects
  - shared ownership and management features
- Common usage
  - open source groups
  - companies
- Create an organization
  - `+` menu (top-right) → “New organization”
  - provide:
    - organization name
    - main contact email
  - optionally invite other users as co-owners
- Free tier note (as stated)
  - organizations are free if everything stored is open source
- Owner capabilities
  - fork a repo into:
    - personal namespace
    - org namespace
  - create repos under:
    - personal account
    - any org you own
  - automatically watch new repos created under the org
- Customization
  - upload an org avatar
- Org landing page
  - lists org repositories and is viewable by others

## Teams
- Teams connect:
  - people (user accounts)
  - repositories
  - access levels
- Example use case
  - repos: `frontend`, `backend`, `deployscripts`
  - team-based permissions for devs vs ops
- Team management includes
  - adding members
  - granting repo access
  - adjusting access levels
- Access levels
  - read-only
  - read/write
  - administrative
- Team invitations
  - invited members get an email
- Team mentions
  - `@org/team` mentions notify all team members and subscribe them
- Team strategy tip
  - users can be in multiple teams
  - create special-interest teams (not only access-control teams)
    - `ux`, `css`, `refactoring`
    - `legal`, `colorblind`, etc.

## Audit log
- Available to organization owners
- Shows
  - org-level events
  - who performed them
  - where they were performed (geographic context)
- Filtering available by
  - event type
  - place
  - person

---

## Scripting GitHub

## Services and Hooks (integrations)

### Where to find
- Repo **Settings**
- **Webhooks and Services** section/tab

### Services (prebuilt integrations)
- Dozens of integrations available
- Common categories
  - CI
  - issue trackers
  - chat systems
  - documentation systems
- Example: Email service
  - choose “email” from “Add Service”
  - configure email address
  - “Add service”
  - result: email sent on every push
- Event model
  - services may support multiple events
  - many focus on push events
- Integration tip
  - check for built-in service for your tool (example given: Jenkins)

### Hooks (generic webhooks)
- Use when
  - you need a custom integration
  - a service isn’t available as a built-in “Service”
- How it works
  - configure a URL
  - GitHub POSTs an HTTP payload to that URL on selected events
- Enabling/configuring
  - click “Add webhook”
  - provide:
    - payload URL
    - secret key
  - choose events (default: push events on any branch)

#### Example webhook service logic (Sinatra)
- Goal example
  - send email if:
    - a specific user pushes
    - to a specific branch
    - touching a specific file
- Steps in the handler
  - parse JSON payload from request body
  - identify:
    - pusher name
    - ref/branch
  - gather files touched across commits (added/modified/removed)
  - if criteria match → send email alert

#### Webhook debugging & redelivery
- GitHub provides a webhook delivery console
  - shows recent deliveries
  - success/failure
  - request/response headers and bodies
- Can “redeliver” old payloads to test your service
- Webhook docs reference
  - `https://developer.github.com/webhooks/`

---

## The GitHub API

### What it’s for
- Automate actions or retrieve information beyond webhook notifications
- Can do (as stated)
  - nearly anything you can do on the website programmatically

### Basic usage (unauthenticated GET)
- Example: user info
  - `curl https://api.github.com/users/schacon`
- Many read-only endpoints exist:
  - orgs, repos, issues, commits, etc.
- Example: get a `.gitignore` template
  - `curl https://api.github.com/gitignore/templates/Java`
- Also mentioned capability
  - render arbitrary Markdown via the API

### Authentication (for write actions/private data)
- Options mentioned
  - basic auth (username/password)
  - personal access token (recommended)

#### Personal access tokens
- Generated in settings → **Applications**
- Configure:
  - scopes
  - description (helps later cleanup)
- Token visibility
  - shown only once → copy it
- Advantages
  - scoped + revocable
  - higher rate limits
    - unauthenticated: 60 requests/hour
    - authenticated: 5,000 requests/hour

### Commenting on an Issue (API example)
- Endpoint pattern
  - `repos/<user>/<repo>/issues/<num>/comments`
- HTTP method
  - `POST`
- Headers
  - `Content-Type: application/json`
  - `Authorization: token TOKEN`
- Example payload
  - JSON with `"body"` (can include emoji codes like `:+1:`)
- Result
  - API returns comment data (id, URLs, timestamps, author info)
  - Comment appears on the GitHub issue

### Changing the status of a Pull Request (commit status API)
- Concept
  - Each commit can have one or more statuses
  - API supports adding/querying statuses
- Typical users
  - CI and testing services
- Other validation examples (as stated)
  - commit message formatting checks
  - contribution guideline validation
  - signed/valid commit checks
- Example webhook-based validator (Signed-off-by)
  - On push:
    - inspect each commit message
    - set status `state` to one of:
      - `success`
      - `failure`
      - `error`
    - include:
      - description
      - target URL for more info
      - context (e.g., `validate/signoff`) to distinguish multiple status providers
  - Status POST endpoint pattern
    - `/repos/<user>/<repo>/statuses/<commit_sha>`
  - UI effect on PR
    - green check vs red X per commit
    - PR overall status reflects last commit’s status
    - warns you if the last commit is failing (useful to avoid merging broken state)

### Octokit (API client libraries)
- Purpose
  - Provide idiomatic wrappers around GitHub API (avoid manual HTTP)
- Languages supported (at time of writing in chapter)
  - Go
  - Objective-C
  - Ruby
  - .NET
- Info link
  - `https://github.com/octokit`

### Documentation link (API)
- Full API docs + guides
  - `https://developer.github.com`

---

## Summary (end of chapter)
- After this chapter you can:
  - create/manage a GitHub account
  - create repos and push code
  - contribute via forks + pull requests
  - review/merge/close PRs as a maintainer
  - manage orgs, teams, audit logs
  - integrate via services/webhooks
  - automate via the GitHub API (tokens, comments, statuses)
- Next step (as stated)
  - learn more powerful Git tools/tips for complex situations to become a “Git master”