GitHub Gists
Lightweight code sharing: creating, editing, forking, and embedding Gists.
Listen
Transcript
Alex: Welcome back. Today we're looking at GitHub Gists, which are one of the lightest ways to share code, notes, examples, and small configuration files.
Jamie: So not a whole project, not a full repository, just a quick shareable thing?
Alex: Exactly. A Gist can hold one file or several files, and each file can have syntax highlighting if GitHub recognizes the extension. It's useful when you want to show a snippet, save a small note, or give someone a reproducible example without creating an entire repo.
Jamie: I like that middle ground. Sometimes an issue comment is too cramped, but a new repository feels like overkill.
Alex: That's where Gists fit nicely. They are small, linkable, and still connected to Git, so you can edit them and keep a history of changes.
Jamie: The appendix that this episode goes with also talks about GitHub Discussions. Before we stay with Gists, can we place Discussions in the workflow?
Alex: Sure. GitHub Discussions is the forum-style area for a repository or an organization. It is where questions, ideas, announcements, polls, and community Q&A can live without turning every conversation into an issue or pull request.
Jamie: So an issue says, there is work to track. A discussion says, let's talk, ask, compare, or decide whether there should be work.
Alex: Right. Use an issue for a bug, a specific feature request, or a task that needs labels, assignees, and closure. Use a discussion for questions, brainstorming, community input, or a topic that may not have one final answer.
Jamie: And the categories help set that expectation before anyone replies.
Alex: They do. Common categories include Q&A for support questions, Ideas for brainstorming, Announcements for maintainer updates, General for everything else, and Show and Tell when community members share what they built.
Jamie: Where does the workshop support hub fit into that?
Alex: For alumni, the Community-Access/support repository is the ongoing support home. Read the pinned Start Here resources in Discussions, search existing threads before starting a new one, and use issues when you have a setup blocker or accessibility blocker that maintainers need to track. In Accessibility Agents work, remember that the catalog grows over time, so Discussions are a good place for questions and ideas, while issues are better for concrete changes.
Jamie: If I'm on a repository page, how do I get to Discussions without hunting around forever?
Alex: Look in the main repository navigation near Code, Issues, Pull Requests, Actions, and Projects. If you use keyboard shortcuts, T can move through tab items, and K can help you find links such as Discussions. If the tab is missing, that usually means the maintainer has not enabled Discussions for that repository.
Jamie: And organizations can have their own Discussions too, right?
Alex: Yes. An organization can host community-wide conversations that are not tied to one repository. On a Discussions home page, categories are usually shown with headings, and a side panel may appear on the left or right depending on the width of the view. That panel can show category counts, pinned items, active discussions, and tags if the project uses them.
Jamie: Creating one sounds similar to opening an issue, but with a category first.
Alex: That's the key difference. Activate New discussion, choose a required category, write a clear searchable title, write the body in Markdown, and start the discussion. For Q&A, phrase the title as a real question, because that title becomes part of how other people search later.
Jamie: What should screen reader users expect in that form?
Alex: The path is usually New discussion, category selection, title field, body editor, and Start discussion. The body editor behaves like an issue comment editor, so enter focus mode when your screen reader needs it, type your content, and Ctrl+Enter can submit. Inside a discussion, replies are often exposed as article elements; NVDA and JAWS users may use A to move among them, while VoiceOver users may prefer headings, links, or the rotor depending on browser setup.
Jamie: And participation is more than just replying at the bottom.
Alex: Yes. You can reply to the main thread, reply to a specific comment with a nested reply, upvote useful posts instead of adding plus-one comments, vote in polls, and, in Q&A threads, the discussion author can mark an accepted answer. Low-vision users may also notice answered badges, percentage bars after poll voting, and success banners that can appear above the current zoom position. If the interface changes, GitHub's own documentation is the reference to check.
Jamie: Okay, back to Gists. If I want to make one from the web, where do I start?
Alex: Go to gist.github.com while signed in. You'll get fields for an optional description, a filename, and the file contents. Name the file with a useful extension, like notes.md, example.py, or config.json, because that helps GitHub choose the right formatting.
Jamie: And then I choose public or secret. This is the part where people can get surprised.
Alex: Yes, and it is important. A public Gist is visible and discoverable. A secret Gist is unlisted, meaning it is not meant to appear in public discovery, but anyone with the link can view it.
Jamie: So secret does not mean private.
Alex: Correct. Don't put passwords, tokens, private keys, personal data, unreleased business information, or anything sensitive in a Gist. Treat secret Gist links as shareable links, not access control.
Jamie: What about multiple files? Can one Gist hold a small example with a script and a README?
Alex: Yes. Use Add file in the web interface and give each file its own name and content. That is handy for a short demo where you want a README, a code file, and maybe a sample output file all traveling together.
Jamie: What if I'm already in the terminal and I don't want to open the browser?
Alex: If you use the GitHub CLI, you can create a Gist with gh gist create. For example, `gh gist create hello.py --public --desc 'small Python example'` creates a public Gist from that file with a short description.
Jamie: And if I want it unlisted instead?
Alex: Use the secret option when you mean unlisted, such as `gh gist create config.json notes.md --secret`. You can pass more than one filename, and the files become part of the same Gist. If you're piping text from another command, give the content a filename so people know what they're reading.
Jamie: After the command runs, how do I know it worked?
Alex: The CLI prints the Gist URL. Open that URL, check the filenames, read the rendered content, and make sure the visibility matches what you intended before sharing it.
Jamie: You said earlier that Gists are connected to Git. Does that mean they have history like repositories?
Alex: They do. A Gist is a Git repository behind the scenes, so edits create revisions. You can edit in the browser, review the revision history, and see what changed over time.
Jamie: Can I clone one locally too?
Alex: Yes. On the Gist page, copy the clone URL, or use the CLI with `gh gist clone` followed by the Gist identifier or URL. Once it's local, you can inspect the files in your editor, make changes, commit, and push if you have permission to update that Gist.
Jamie: And comments live on the Gist page, not in my local clone.
Alex: Right. Gist comments are for discussion around the snippet or note. To add one, open the Gist page, move to the comment editor near the bottom, type your message, and submit it much like an issue comment.
Jamie: Gists also have stars and forks. Are those the same as repository stars and forks?
Alex: Similar idea, smaller scale. Starring a Gist saves or signals appreciation for it. Forking a Gist makes your own copy under your account, so you can modify it without changing the original.
Jamie: But I shouldn't expect the whole repository collaboration system.
Alex: Exactly. A Gist doesn't give you the same project structure, issue tracker, pull request workflow, releases, or automation that a full repository does. It is lightweight sharing, not a complete project home.
Jamie: How do I find my own Gists later?
Alex: Use the Gists area from your GitHub profile, go directly to gist.github.com, or visit gist.github.com followed by your username. Screen reader users can move by headings and links to the Gist list, then open titles. You can also browse public Gists through GitHub's Gist discovery areas or arrive at them through links, search results, and community posts.
Jamie: Embedding sounds useful. What does it mean to embed a Gist in a web page?
Alex: It means placing the Gist content inside another page, usually a blog post, lesson, or documentation page. On the Gist page, GitHub provides an embed script you can copy and paste into an HTML page.
Jamie: So the page shows the snippet without me re-copying all the code by hand.
Alex: Yes, and if you update the Gist, the embedded version can reflect that update. For accessibility, don't rely only on the embedded script. Add a short plain-language summary and a direct link to the Gist, so people have another route if scripts are blocked, slow, or awkward with their setup.
Jamie: Give me a few situations where a Gist is the right tool.
Alex: A good one is sharing screen reader configuration notes, like NVDA settings for GitHub web navigation. Another is a quick Markdown note, such as Workshop Day 1 notes, where the content is useful but not a project. A third is a code snippet for an answer on Stack Overflow or in a support thread.
Jamie: And when should I stop and make a real repository instead?
Alex: Use a repository when the work has a project shape: a README, folders, tests, issues, pull requests, releases, permissions, or ongoing collaboration. Use a Gist when the work is small, self-contained, and easy to understand as a snippet or note.
Jamie: So a Gist is great for showing a pattern. A repository is better for maintaining a thing.
Alex: Nicely put. If you expect other people to file bugs, propose changes, run workflows, or follow a roadmap, give the work a repository.
Jamie: Let's end with the safety check, because secret Gists can sound safer than they are.
Alex: They can, and the rule is simple: never put sensitive data in Gists. Public Gists are discoverable. Secret Gists are link-accessible. Neither one is a password vault.
Jamie: If I accidentally put a token in a Gist and then delete the Gist, am I safe?
Alex: No. If a secret or public value was exposed, rotate or revoke it as soon as possible. Deleting the Gist removes the page from your account, but you cannot assume nobody copied the content, cached it, or followed the link while it existed.
Jamie: How do I delete one when I really do want it gone?
Alex: Open the Gist, find its delete control, confirm the deletion, and then verify it no longer appears in your Gists list. For routine cleanup, that's enough. For leaked secrets, cleanup is only the first step; revocation is the real fix.
Jamie: So the everyday workflow is: use Gists for small shareable material, be clear about visibility, and move to a repository when the work needs a real home.
Alex: Exactly. Gists are small, but they're not throwaway. Used well, they make examples easier to share, easier to revise, and easier for someone else to understand.
Workshop Content
Companion Podcast and Transcript
Use audio and transcript companions to review concepts in a conversational format.
GitHub Gists
Companion audio: this episode reinforces key ideas and may not be a word-for-word reading of this page.
Open audio file (external) Full transcript source (external)
Transcript preview
Alex: Welcome back. Today we're looking at GitHub Gists, which are one of the lightest ways to share code, notes, examples, and small configuration files.
Jamie: So not a whole project, not a full repository, just a quick shareable thing?
Alex: Exactly. A Gist can hold one file or several files, and each file can have syntax highlighting if GitHub recognizes the extension. It's useful when you want to show a snippet, save a small note, or give someone a reproducible example without creating an entire repo.
Jamie: I like that middle ground. Sometimes an issue comment is too cramped, but a new repository feels like overkill.
GitHub Discussions
Companion audio: this episode reinforces key ideas and may not be a word-for-word reading of this page.
Open audio file (external) Full transcript source (external)
Transcript preview
Alex: Welcome back. Today we're talking about GitHub Discussions, which is GitHub's built-in forum space for a repository or an organization.
Jamie: So not an issue, not a pull request, but still part of the project conversation.
Alex: Exactly. Discussions are for threaded community conversations: questions, ideas, announcements, polls, and show-and-tell posts. They sit beside the more action-focused tools, so the community can talk without turning every question into a task.
Jamie: I like that distinction, because a lot of people hesitate before posting. They wonder, am I making work for someone just by asking this?
Appendix U: Discussions and Gists
Reference companion to: Chapter 08: Open Source Culture | Also relevant: Chapter 10
Authoritative source: GitHub Docs: About discussions
This appendix consolidates two related community content features: GitHub Discussions (formerly Appendix G) and GitHub Gists (formerly Appendix F).
GitHub Discussions
Listen to Episode 24: GitHub Discussions - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned.
Forum-Style Conversations Beyond Issues and Pull Requests
GitHub Discussions is a built-in community forum for repositories and organizations. It's where open-ended conversations live - questions, ideas, announcements, polls, and community Q&A - separate from the action-oriented world of issues and pull requests.
Support Hub Onboarding (Recommended For Workshop Alumni)
For ongoing support after the workshop, use:
- Support hub home: Community-Access/support
- Q&A and community discussion: Support Hub Discussions
- Trackable support requests: Support Hub Issues
Suggested first steps for students:
- Read the pinned Start Here resources in Discussions.
- Search existing discussions before opening a new support thread.
- Use issue templates for setup blockers or accessibility blockers so maintainers can help faster.
Learning Cards: GitHub Discussions
Screen reader users
- The Discussions tab is in the repository's main navigation bar alongside Code, Issues, and Pull Requests -- press
Tto navigate tab items orKto find the "Discussions" link - Inside a discussion, replies are
articleelements -- in NVDA pressAto jump between replies; in JAWS useAas well - The reply editor uses the same behavior as issue comments -- enter Focus Mode to type, then press
Ctrl+Enterto submit
Low vision users
- Discussion categories appear as a sidebar panel on the left or right depending on viewport width -- look for the category list with item counts
- Answered discussions in the Q&A category display a green "Answered" badge next to the title, with the accepted answer pinned to the top
- Polls show percentage bars next to each option after you vote -- the bars use color fill to indicate proportion
Sighted users
- Discussions are organized by category with colored labels -- the sidebar shows all categories and pinned items
- In Q&A threads, look for the green checkmark on the accepted answer pinned above the regular reply timeline
- Use the upvote button (thumbs up) on replies instead of posting "+1" comments -- maintainers often sort by upvotes
Table of Contents
- Discussions vs. Issues: When to Use Which
- Navigating to Discussions
- Discussion Categories
- Creating a Discussion
- Participating in Discussions
- Marking an Answer
- Polls
- Screen Reader Navigation Reference
- Organization-Level Discussions
- Accessibility Agents: What's Different Here
1. Discussions vs. Issues: When to Use Which
Not every conversation belongs in an issue. GitHub Discussions exists for the conversations that don't fit:
| Use Issues When | Use Discussions When |
|---|---|
| You found a bug | You have a question about how something works |
| You want to request a specific feature | You want to brainstorm ideas before filing a feature request |
| There is actionable work to be done | You want community input before deciding what work to do |
| You need to track progress (labels, assign, close) | You want to have an open conversation without resolving it |
| The answer is "fixed" or "won't fix" | The conversation might not have one right answer |
The signal for maintainers: A question in an issue is noisier - it implies something needs to be done. The same question in Discussions doesn't trigger workflow automation and doesn't inflate the issue count.
Common Discussions categories you'll encounter
- Q&A - Support questions and answers (one answer can be marked correct)
- Ideas - Feature brainstorming before a formal feature request
- Announcements - Maintainer posts about releases, breaking changes, roadmaps
- General - Everything else
- Show and Tell - Community members showing what they built
2. Navigating to Discussions
From a Repository
- Navigate to the repository
- There is a Discussions tab in the main navigation (alongside Code, Issues, Pull Requests, Actions, Projects)
- Press
Tto navigate tab items, orKto navigate links and find "Discussions" - Press
Enterto open
If the tab is missing: Discussions is an opt-in feature. The repository maintainer must enable it in Settings. Not all repositories use it.
From an Organization
Large organizations can have organization-level Discussions separate from any individual repository:
- Navigate to the organization page
- Look for the Discussions tab at the organization level
- These are community-wide conversations, not repo-specific
3. Discussion Categories
The Discussions home page is organized by category. Each category is a section with its own heading.
Navigating categories
3 → Jump to category headings
K → Navigate discussion titles within a category
Enter → Open a discussion
The side panel (left or right depending on view width) shows
- All categories with item counts
- Pin/announcements section at top
- Most active discussions
- Tags (if the repo uses them)
4. Creating a Discussion
- From the Discussions tab, activate "New discussion" button
- Select a category (required - affects which fields appear)
- Fill in:
- Title - Clear and searchable. "How do I use the daily-briefing agent?" not "Help"
- Body - Use Markdown. Same editor as issues
- For Q&A category: phrase the title as a question
- Activate "Start discussion"
Screen reader path
Tab to "New discussion" button → Enter
→ Category list: ↑/↓ to select category → Enter
→ Title field: type title
→ Tab to body: Focus Mode → type or paste content
→ Tab to "Start discussion" button → Enter
Before posting a question: Search existing discussions first. Use the search bar at the top of the Discussions page or GitHub's global search with repo:owner/name in:discussions.
Learning Cards: Creating a Discussion
Screen reader users:
- Tab to the "New discussion" button from the Discussions tab, then press Enter -- the form loads with a category selector first; arrow through categories and press Enter to select
- The title field comes after the category selector -- type a clear, searchable title; for Q&A category, phrase it as a question so it reads naturally in search results
- The body editor is the same as the issue comment editor -- enter Focus Mode to type, use Markdown formatting, and press
Ctrl+Enterto submit the discussion
Low-vision users:
- The category selector appears as a list or grid of labeled options -- each category has a name and description; zoom in to read the descriptions and pick the right one
- The title and body fields stack vertically in a single-column layout -- the form is the same width as the main content area, making it easy to scan at high zoom
- After creating a discussion, a green success banner appears at the top -- scroll up if you do not see confirmation at your current zoom position
Sighted users:
- Categories appear as clickable cards or a list when creating a new discussion -- choose Q&A for questions (allows marking an answer), Ideas for brainstorming, General for everything else
- The "New discussion" button is prominently placed at the top-right of the Discussions tab -- the form layout is nearly identical to the new issue form
- Search existing discussions before posting -- use the search bar at the top of the Discussions page to avoid duplicate questions
5. Participating in Discussions
Reading a Discussion
A discussion page is structured similarly to an issue:
- The original post at the top
- Replies in chronological order
- An "Answered" reply pinned to the top (Q&A category only)
- A reply editor at the bottom
Navigation
H → Jump between the original post heading and reply headings
3 → Navigate individual reply headings
↓ → Read through content
Replying to a Discussion
- Navigate to the bottom of the page (or use the "Reply" button on a specific comment)
- The reply text area behaves identically to issue comments
- Focus Mode → type your reply
Ctrl+Enterto submit
Replying to a Specific Comment (Nested Reply)
Each comment has a Reply button below it:
Tab to "Reply" button on the specific comment → Enter
→ Nested text area opens under that comment
→ Focus Mode → type → Ctrl+Enter
Upvoting
Instead of leaving "+1" comments, use the thumbs-up reaction on the original post or replies. Many maintainers sort discussion responses by upvotes to prioritize most-needed answers.
6. Marking an Answer
In the Q&A category, one reply can be marked as the accepted answer. This is similar to Stack Overflow's "accepted answer" mechanic.
Only the discussion author and repository maintainers can mark an answer.
To mark an answer (as the discussion author)
- Navigate to the reply you want to mark as the answer
- Look for the "Mark as answer" button below the reply
- Activate it - the reply is pinned to the top and the discussion shows a green "Answered" badge
Why it matters: Marked answers make Q&A discussions into searchable documentation. Anyone who searches for the same question later immediately sees the correct answer without reading the whole thread.
To unmark an answer: Activate "Unmark as answer" on the same reply.
7. Polls
Some discussion categories support embedded polls. A poll lets you gather structured vote data from the community.
Creating a poll
- When creating a discussion, look for the "Add a poll" option below the body editor
- Type each poll option (up to 8 options)
- Set poll duration (optional)
- Submit the discussion - the poll appears inline
Voting in a poll
Navigate to the poll section
→ Radio buttons or checkboxes for each option
→ Space/Enter to vote
→ "Vote" button → Enter
Poll results: After voting, percentages appear next to each option. Screen readers announce the count and percentage per option.
8. Screen Reader Navigation Reference
Discussions List
T → Navigate tab bar to reach "Discussions" tab
H / 2 → Category section headings
3 → Individual discussion titles (h3 links)
K → Navigate all links (discussions, categories, pagination)
Enter → Open a discussion
/ → Focus the search bar (if supported)
Inside a Discussion
H → Original post heading and top-level reply headings
3 → Individual replies
↓ → Read body content
Tab → Move to interactive elements (reply buttons, reactions, mark as answer)
Ctrl+Enter → Submit a reply (when in text area)
NVDA note
- Browse mode (NVDA+Space) to read the discussion
- Enter application mode for the reply editor
- Discussion replies are
<article>elements - NVDA announces "article" as you navigate with H
JAWS note
Akey navigates<article>elements - useful for jumping between replies- Use Forms Mode for the reply editor
VoiceOver note
- VO+Right to read through content
- VO+Command+L to list all links (useful for navigating many replies quickly)
- VO+Space on the reply field to enter interaction mode
9. Organization-Level Discussions
Some organizations enable Discussions at the organization level, separate from any repository. These work identically to repository discussions but span the whole organization.
Common uses:
- Org-wide announcements
- Community introductions ("Introduce yourself" pinned thread)
- Cross-repo feature brainstorming
- Community spotlights and events
Find them at github.com/ORGANIZATION/discussions.
10. Accessibility Agents: What's Different Here
Accessibility Agents prompts currently operate on issues, PRs, and code - not directly on Discussions. If you want to respond to a discussion using Accessibility Agents:
- Copy the discussion URL or content
- Use
/issue-replywith the content pasted in: the agent will draft a thoughtful, accessible response - Paste the result back into the discussion reply editor
This works well for first-response drafts on Q&A threads or community questions in your area of expertise.
Return to: Resources | Glossary
GitHub Gists
Listen to Episode 23: GitHub Gists - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned.
Shareable Code Snippets and Notes
Gists are a simple way to share code snippets, notes, or small files without creating a full repository. Think of them as lightweight, version-controlled pastebins.
Learning Cards: GitHub Gists
Screen reader users
- On the Gist creation page at gist.github.com, press
Dto jump to the main landmark, thenFto navigate form fields: Description, Filename, Content, and Visibility buttons - Your Gists page lists each gist as an
H2heading with its description -- press2orHto jump between gists - Gists are full Git repositories -- you can clone them with
git cloneand edit locally using your usual screen reader workflow in VS Code
Low vision users
- Gist pages use syntax highlighting matching GitHub's current theme -- switch between light and dark mode for comfortable reading
- Public and secret gists look identical on the page; the only difference is the URL visibility -- check the "Create secret gist" or "Create public gist" button label before submitting
- The revision history link appears at the top of any gist -- click "Revisions" to see a diff view of every edit
Sighted users
- Gists live at gist.github.com, separate from regular repositories -- each gist shows a syntax-highlighted code block with filename tabs at the top
- The visibility selector is a split button at the bottom of the editor -- the dropdown arrow reveals "Create secret gist" vs "Create public gist"
- You can add multiple files to one gist using the "Add file" button below the first editor pane
What Is a Gist?
A Gist is a Git repository that holds a single file or a small collection of files. Every Gist:
- Has its own URL (e.g.,
gist.github.com/username/a1b2c3d4) - Is version-controlled (you can see edit history)
- Can be public (anyone can see) or secret (only people with the link can see)
- Supports Markdown rendering
- Can be embedded in web pages
- Can be cloned, forked, and starred just like repos
Secret does not mean private. Anyone with the URL can view a secret Gist. It's just not listed publicly on your profile.
When to Use a Gist vs a Repository
| Use a Gist When... | Use a Repository When... |
|---|---|
| Sharing a single code snippet | Building a full project |
| Posting configuration examples | Collaborating with multiple people |
| Quick notes or documentation | Need issues, PRs, or project management |
| Sharing logs or error messages | Want CI/CD and automated checks |
| Small utility scripts | Need multiple branches |
Creating a Gist
Via GitHub Web Interface
- Navigate to gist.github.com
- Gist description: A short title (e.g., "NVDA configuration for GitHub")
- Filename: Name your file with extension (e.g.,
nvda-config.txt,script.py,notes.md) - Content: Paste or type your code/text
- Visibility:
- Select "Create public gist" for openly shareable content
- Select "Create secret gist" for link-only sharing
- The Gist is created with a unique URL you can share
Screen reader navigation
Dto cycle landmarks to "Main"Fto navigate form fields- Tab through: Description → Filename → Content textbox → Visibility buttons
Adding Multiple Files to a Gist
You can add multiple files to a single Gist:
- After typing the first filename and content, select "Add file" (button below the editor)
- Repeat for each additional file
- Create the Gist
Use case: Share related config files together (e.g., .vscode/settings.json + .vscode/keybindings.json)
Learning Cards: Creating a Gist
Screen reader users:
- On the Gist creation page at gist.github.com, press
Dto jump to the main landmark, thenFto navigate form fields in order: Description, Filename, Content textarea, and visibility buttons - The visibility selector is a split button -- the main button creates a public gist; Tab to the dropdown arrow next to it and press Enter to reveal the "Create secret gist" option
- Each filename field has a corresponding content textarea directly below it -- after filling one file, Tab to the "Add file" button to add another file to the same gist
Low-vision users:
- The Gist editor uses the same syntax highlighting as regular GitHub files -- your current theme applies; increase font size in browser zoom for comfortable editing
- The split button for public vs. secret visibility is at the bottom of the form -- the two options look nearly identical; read the button label carefully ("Create public gist" vs. "Create secret gist") before clicking
- The "Add file" button appears below the first file editor as a small text link -- zoom in to find it; each additional file gets its own filename field and content textarea
Sighted users:
- The Gist creation form has three main fields stacked vertically: description at the top, then filename, then a large code editor -- fill all three before choosing visibility
- The visibility split button at the bottom-right has a dropdown arrow -- click the arrow to choose between public and secret; the default (larger) button creates a public gist
- Add multiple files to a single gist using the "Add file" link below the editor -- multi-file gists are useful for sharing related configurations or code snippets together
Editing a Gist
- Navigate to your Gist's URL
- Select "Edit" (button in the top-right)
- Make your changes
- Select "Update public gist" or "Update secret gist"
Every edit creates a new revision. Click "Revisions" to see the full edit history.
Embedding a Gist
You can embed Gists in web pages, blog posts, or documentation:
<script src="https://gist.github.com/username/gist-id.js"></script>
GitHub renders it as a formatted code block with syntax highlighting and a link back to the Gist.
Accessibility note: Embedded Gists are <iframe> elements. Screen readers will announce them as "frame" and allow navigation into the content.
Cloning a Gist
Every Gist is a Git repository. You can clone it:
git clone https://gist.github.com/username/gist-id.git
Make changes locally, commit, and push just like a normal repo.
Forking a Gist
You can fork someone else's Gist to create your own copy:
- View the Gist
- Select "Fork" in the top-right
- GitHub creates a new Gist under your account
Use case: Someone shares a useful script, you fork it, and customize it for your needs.
Finding Your Gists
Your Gists page: gist.github.com/your-username
All your public and secret Gists are listed here. You can:
- Search your Gists by filename or content
- Star Gists you want to reference later
- Delete old Gists
Screen reader navigation
- Each Gist appears as a heading (H2) with its description
- Press
2orHto jump between Gists - Each Gist has links: "Edit," "Delete," "Star," "Embed"
Discovering Public Gists
Browse trending Gists: gist.github.com/discover
See popular Gists by language. Great for finding:
- Useful scripts and utilities
- Configuration examples
- Code snippets for learning
Gist Comments
Public Gists support comments. Anyone with a GitHub account can leave a comment, making Gists useful for:
- Asking questions about a snippet
- Suggesting improvements
- Discussing implementation details
To add a comment
- Scroll to the bottom of the Gist page
Fto navigate form fields → Find the comment textarea- Type your comment (Markdown supported)
Ctrl+Enteror activate "Comment" button
Security and Privacy
Public Gists
- Appear on your profile
- Are indexed by search engines
- Anyone can view, fork, and comment
Secret Gists
- Do not appear on your profile
- Are not indexed by search engines
- Anyone with the URL can view
- Still version-controlled and can be starred
Never put sensitive data in Gists
- Passwords or API keys
- Personal identifying information
- Proprietary code you don't have permission to share
If you accidentally post sensitive data:
- Delete the Gist immediately
- Revoke/regenerate any exposed credentials
- Remember: Forks and clones may still exist
Example Use Cases
1. Sharing Screen Reader Config
Filename: nvda-github-config.txt
Content:
# NVDA Settings for GitHub Web Navigation
- Browse Mode: Use screen layout (enabled)
- Verbosity: Most punctuation
- Rate: 65%
- Keyboard shortcuts: Use standard GitHub shortcuts (G+I, G+P, etc.)
Share the Gist URL with other screen reader users.
2. Quick Markdown Note
Filename: workshop-notes.md
Content:
# Workshop Day 1 Notes
- GitHub Flow: branch → commit → PR → review → merge
- Keyboard shortcuts: G+I (issues), G+P (PRs), / (search)
- Always link PRs to issues with "Closes #N"
Reference it later or share with workshop participants.
3. Code Snippet for a StackOverflow Answer
When answering questions, paste your code as a Gist and link to it. Readers get syntax highlighting, version history, and the ability to fork your solution.
Gists vs GitHub Repositories - Quick Comparison
| Feature | Gist | Repository |
|---|---|---|
| Issues | No | Yes |
| Pull Requests | No | Yes |
| GitHub Actions | No | Yes |
| Projects | No | Yes |
| Multiple branches | No | Yes |
| Revisions/history | Yes | Yes |
| Forkable | Yes | Yes |
| Embeddable | Yes | No |
| Comments | Yes | Yes (on issues/PRs) |
Deleting a Gist
- Navigate to the Gist
- Select "Edit"
- Select "Delete" (top-right, after Edit button)
- Confirm deletion
Next: Appendix V: GitHub Mobile
Back: Appendix T: Community and Social
Teaching chapter: Chapter 08: Open Source Culture
Authoritative Sources
Use these official references when you need the current source of truth for facts in this chapter.
Section-Level Source Map
Use this map to verify facts for each major section in this file.
- GitHub Discussions: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs, About Git
- Forum-Style Conversations Beyond Issues and Pull Requests: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs, About Git
- 1. Discussions vs. Issues: When to Use Which: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs, About Git
- 2. Navigating to Discussions: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs
- 3. Discussion Categories: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs
- 4. Creating a Discussion: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs
- 5. Participating in Discussions: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs
- 6. Marking an Answer: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs
- 7. Polls: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs
- 8. Screen Reader Navigation Reference: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs, W3C Web Content Accessibility Guidelines (WCAG) 2 overview
- 9. Organization-Level Discussions: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs
- 10. Accessibility Agents: What's Different Here: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs, GitHub Copilot docs
- GitHub Gists: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs, About Git
- Shareable Code Snippets and Notes: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs
- What Is a Gist?: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs
- When to Use a Gist vs a Repository: GitHub Docs, home, GitHub Changelog, GitHub Discussions docs, GitHub Gists docs, About Git