Exam Guide : GitHub Foundation Part 2

Contribution to open-source project on GitHub

Find an Open-Source Project That Needs Contributions

The easiest way to start contributing is to look at the projects you already use or want to use. Since you’re familiar with them, you’ll have a better understanding of how they work and where they can improve.

Here are some common opportunities to contribute:

• Fix typos or broken links in the README or documentation.
• Update outdated documentation to make it clearer for new users.
• Report bugs or fix small issues you’ve encountered.
• Add tests or improve existing test coverage.
• Improve accessibility or translations to make the project more inclusive.

Understand Project Guidelines Before Contributing

Every open-source community is unique, with its own culture and participation rules. Once you’ve found a project you’d like to contribute to, take time to familiarize yourself with its guidelines. This ensures your contributions align with the project’s expectations and community standards.

Most open-source repositories include key documents at the top level:

• LICENSE – Defines how the project can be used, shared, or modified. If no license is present, the project is not truly open source.
• README – The welcome page of the project, usually explaining what it does, how to get started, and how to engage with the community.
• CONTRIBUTING – Provides step-by-step instructions for contributing, including setup details and the review process.
• CODE_OF_CONDUCT – Outlines expected behavior and community standards, ensuring a safe and welcoming environment.

Identify Tasks to Work On

Once you’ve chosen a project and reviewed its contribution guidelines, the next step is to find tasks where you can contribute.

You might start small—fixing a broken link, updating documentation, or reporting a bug you’ve noticed. To discover structured opportunities:

• Visit the project’s /contribute URL, which highlights beginner-friendly issues.
• Look for labels such as:
  • good first issue – simple issues ideal for new contributors.
  • help wanted – tasks where maintainers are actively seeking assistance.
  • beginner-friendly – issues designed to welcome new contributors.
  • discussion – opportunities to provide input or feedback.

Sponsor a project

Contributing to open source isn’t limited to writing code—financial support is also a powerful way to give back. Many open-source projects are maintained by volunteers who dedicate their time and skills to building, securing, and improving the tools we all rely on.

• With GitHub Sponsors, you can directly fund individuals or projects. Sponsorship helps maintainers:
• Continue improving their projects.
• Cover costs for infrastructure, tools, or security.
• Receive recognition for their work and community impact.

Contribute to an open-source repository

Once you’ve identified a task or area to contribute, the next step is preparing your contribution. Success in open source isn’t just about writing code—it’s also about clear communication and collaboration.

Why Communication Matters

• It prevents duplication of effort (two people working on the same issue).
• It ensures your contribution aligns with the project’s goals and practices.
• It fosters collaboration and makes it more likely your work will be accepted.

Communicate Your Intent to Maintainers

Before diving into any work, it’s important to communicate your intent to contribute. This helps avoid duplication, ensures alignment with project goals, and opens the door for feedback from maintainers.

• Working on an existing issue

  • Check the Assignees section to see if anyone is already working on it.
  • Look at the Linked pull requests section—if there’s a PR, someone may already be addressing the issue.
  • Read through the comments to confirm no one else has claimed it.
  • If the issue is available, post a comment to state your interest. This signals to others that you’re taking it on and invites maintainers to provide guidance.

• Proposing a new issue or feature

  • If your bug or feature isn’t listed in the issue tracker, create a new issue.
  • Follow any issue template provided.
  • Clearly explain the problem, your proposed solution, and your intent to work on it.
  • For larger features or changes, wait for maintainer approval before moving forward.

Manage an InnerSource program by using GitHub

What is InnerSource?

Open source allows anyone to freely use, view, modify, and share software, with the belief that open collaboration leads to better and more reliable solutions.

InnerSource applies these open-source practices inside an organization. In other words, it’s like running an open-source project behind your company’s firewall. An InnerSource program mirrors the structure of open source—issues, pull requests, discussions—but limits access to the company’s employees.

Benefits of InnerSource

• Internal Visibility

  • Developers gain access to other teams’ code, issues, and project plans.
  • Encourages code reuse and learning from existing solutions.
  • Improves productivity by reducing duplication of effort.

• Reduced Friction

  • Teams dependent on fixes or new features can directly propose changes.
  • If contributions can’t be merged, consumer teams can fork the project to meet their needs.
  • Creates smoother collaboration between otherwise siloed teams.

• Standardized Practices

  • Promotes consistent contribution models across teams.
  • Standardizes how processes and communication are documented.
  • Makes it easier for any developer in the company to contribute to any project.

Set up an InnerSource program on GitHub

Set repository visibility and permissions

GitHub repositories can be configured with different visibility levels and permission levels to control who can see and interact with your project.

Repository Visibility

• Public

  • Visible to everyone, inside and outside your organization.
  • Best for open-source projects.

• Internal (GitHub Enterprise only)

  • Visible only to members of the enterprise.
  • Ideal for InnerSource projects.

• Private

  • Visible only to the repository owner and explicitly added users or teams.
  • Use this for projects requiring restricted access.

Users who don’t meet the visibility requirement will see a “not found” page when trying to access the repo.

Repository Permission Levels

Once visibility is set, you can assign fine-grained permissions:

• Read – View and discuss the project (good for non-code contributors).
• Triage – Manage issues and pull requests without write access.
• Write – Push code and actively contribute to the project.
• Maintain – Manage repository settings (excluding sensitive/destructive actions).
• Admin – Full access, including sensitive actions like security management or deleting the repo.

Create Discoverable Repositories

As your InnerSource program grows, it’s important to make repositories easy to find and use. Follow these best practices:

• Use a descriptive name (e.g., warehouse-api, supply-chain-web).
• Add a concise description (1–2 sentences explaining purpose).
• License the repository so users know how they can use and share it.
• Include a README.md as the landing page with setup and usage info.

How GitHub Surfaces Your README

When you add a README.md file, GitHub automatically displays it on the repository’s landing page. The file can be placed in:

• .github directory (highest priority)
• Repository root directory
• docs directory

If multiple README files exist, GitHub follows this order of priority when deciding which one to display.

Manage Projects on GitHub

To make collaboration smoother, GitHub automatically looks for a CONTRIBUTING.md file in your repository (in the root, /docs, or /.github directory).

This file should outline your project’s contribution policy, including conventions, workflows, and expectations for contributors.

If a CONTRIBUTING.md file exists, GitHub will display a link to it whenever someone opens an issue or a pull request, encouraging contributors to follow your guidelines.

Create issue and pull request templates

GitHub lets you create starter templates for issues and pull requests to make contributions more structured and consistent.

• Issue Templates (.github/ISSUE_TEMPLATE.md)

  • Automatically load when someone creates a new issue.
  • Help contributors provide all required details without referring back to CONTRIBUTING.md.
  • Work like a form—users just fill in the template.

• Pull Request Templates (.github/PULL_REQUEST_TEMPLATE.md)

  • Provide a standard structure for PR descriptions.
  • Encourage contributors to include details like the purpose of changes, testing steps, and related issues.

Maintain a secure repository by using GitHub repository

A secure development strategy is critical to protect data, prevent unauthorized access, and ensure compliance.

Key considerations:

• Educate continuously – Security evolves, so ongoing training is essential.
• Write secure code – Design and implement features with security in mind.
• Ensure compliance – Test against regulations during development and after deployment.

Security Tab

GitHub offers security features that help keep data secure in repositories and across organization. Security Tab in a specific repository consists of the below options:

From the Security tab, you can add features to your GitHub workflow to help avoid vulnerabilities in your repository and codebase. These features include:

• Security policies that allow you to specify how to report a security vulnerability in your project by adding a SECURITY.md file to your repository.
• Dependabot alerts that notify you when GitHub detects that your repository is using a vulnerable dependency or malware.
• Security advisories that you can use to privately discuss, fix, and publish information about security vulnerabilities in your repository.
• Code scanning that helps you find, triage, and fix vulnerabilities and errors in your code.
• Secret scanning that detects tokens, credentials, and secrets committed to your repo and can block them before the push. Push protection is enabled by default on public repositories.

Communicate a Security Policy with SECURITY.md

Include a SECURITY.md file in your repository to guide responsible disclosure of vulnerabilities. It helps researchers and contributors report issues safely and ensures faster resolution of security concerns.

Keep Sensitive Files Out of Your Repository with .gitignore

Accidentally committing sensitive files—like API keys or private configs—can expose serious security risks. A .gitignore file prevents this by telling Git which files or patterns to ignore during commits.

• Helps avoid committing build artifacts, logs, or secrets.
• Supports multiple .gitignore files; child directory rules override parent ones.
• Maintain a root .gitignore for global rules, with optional project-specific files where needed.

Branch protection rules

Branch protection rules help enforce workflows and maintain code quality before changes are merged. For example, you can require an approving review or passing status checks for pull requests targeting protected branches.

Common workflows include:

• Running builds to verify code compiles.
• Running linters to enforce coding standards.
• Running automated tests to catch regressions.
• Enforcing reviews and status checks before merging.

Add a CODEOWNERS File

A CODEOWNERS file defines who is responsible for specific parts of a repository. When someone opens a pull request that modifies those files, GitHub automatically requests a review from the designated code owners.

Key points:

• Place the CODEOWNERS file in the root, .github/, or docs/ directory.
• Use file patterns to specify ownership (e.g., *.js @frontend-team).
• Multiple owners can be assigned to the same file or directory.
• Helps enforce accountability and ensures the right people review changes.

Automated Security in GitHub

GitHub provides several built-in automated security features to help you identify and remediate risks in your repositories.

Repository Dependency Graphs

• GitHub scans package manifests (e.g., package.json, requirements.txt).
• Creates a dependency graph to show all direct and indirect dependencies.

Dependabot Alerts

• Monitors your dependency graph for known vulnerabilities.
• Cross-references package versions with GitHub Security Advisories.
• Sends alerts when a risk is detected.

Dependabot Automated Updates

• Dependabot doesn’t just alert you—it can create pull requests to update vulnerable dependencies automatically.
• Maintainers review, test, and merge these PRs to stay secure with minimal effort.

Automated Code Scanning

• Scans your code for security vulnerabilities and coding errors.
• Prevents new issues from being introduced in pull requests.
• Powered by CodeQL, which lets you query code as data and use custom or community-maintained queries.

Secret Scanning

• Detects hardcoded secrets (API keys, tokens, credentials) in repositories.
• Enabled by default for public repos; can be enabled for private repos by admins.
• Alerts service providers, who may revoke or rotate exposed credentials.

GitHub Administration

GitHub provides different levels of administration—team, organization, and enterprise—each offering specific controls and best practices for managing collaboration, security, and policies.

Administration at the Team Level

Teams are substructures within organizations that simplify permission management and collaboration.

• Capabilities for team maintainers / repo admins:

  • Create, delete, or rename teams.
  • Add/remove members or sync membership with IdP groups (e.g., Microsoft Entra ID).
  • Manage outside collaborators (consultants, contractors).
  • Enable/disable team discussions and set visibility.
  • Assign automatic code reviewers and schedule reminders.

• Best practices:

  • Create nested teams to reflect company hierarchy.
  • Build interest/skill-based teams (e.g., JavaScript, data science) to streamline PR reviews.
  • Use IdP synchronization to automate onboarding/offboarding and reduce manual updates.

Administration at the Organization Level

Organizations are shared spaces where multiple teams collaborate across repositories.

• Owner/administrator capabilities:

  • Invite or remove members.
  • Create teams and grant maintainer permissions.
  • Manage repository permissions and default settings.
  • Add/remove outside collaborators.
  • Configure security and billing.
  • Apply organization-wide changes or migrations using scripts.

• Best practices:

  • Ideally set up one organization to simplify management.
  • Multiple organizations increase setup effort, risk of misconfiguration, and may add costs.

Administration at the Enterprise Level
Enterprise accounts (GitHub Enterprise Cloud or Server) allow centralized management across multiple organizations.

Owner capabilities:

• Enable SAML single sign-on with IdP integration.
• Add or remove organizations.
• Manage enterprise-wide billing.
• Define global repository, project, and team policies.
• Apply migrations or custom scripts across the enterprise.
• Use GitHub Connect to integrate Enterprise Server with GitHub.com.

How does GitHub organization and permissions work?

Organizations in GitHub allow multiple people to collaborate on repositories while controlling access with permission levels, forking rules, and insights.

• Repository Permission Levels
  Repositories support five standard permission levels:

  • Read – View or discuss project content (non-code contributors).
  • Triage – Manage issues and pull requests without write access (ideal for project managers).
  • Write – Push commits and make direct contributions (standard for developers).
  • Maintain – Manage repository settings without destructive actions (for project leads).
  • Admin – Full access, including sensitive actions like security management or deleting the repo (for admins/owners).

• What is Repository Forking?

Forking creates a personal copy of a repository under your account. This allows experimentation or contributions without affecting the original project.

• Public repos → Always forkable.
• Private repos → Forking can be disabled or restricted to org members.
• Internal repos → Can only be forked within the same enterprise account.

Note: If you disable forking for a private repository, no one (including organization members) will be able to fork it.

• Viewing Repository Insights

The Insights tab provides data to track repository health, activity, and security.

• Contributors – See commits, additions, and deletions by contributor.
• Traffic – Monitor unique visitors and page views.
• Commits – Analyze commit activity over time.
• Code Frequency – Track lines added and deleted.

• Dependency Graph – Identify and monitor dependencies for vulnerabilities.

  • Best Practices with Insights:

• Monitor contributor activity to identify engaged team members.

• Track traffic trends to understand repository engagement.

• Regularly review the dependency graph to address security risks.

Managing enterprise permissions

GitHub provides different permission levels at both the organization and enterprise levels. These roles help maintain security, proper access, and governance across teams.

Organization Permissions Levels

Role	Description
Owner	Full control of the organization. Can add/remove members. Should be limited to at least two people for safety.
Member	Standard role. Can create and manage repositories and teams.
Moderator	Manage community interactions in public repositories (block/unblock contributors, set interaction limits, hide comments).
Billing Manager	Manage organization billing information.
Security Manager	Manage security alerts and settings across the organization; read access to all repositories.
Outside Collaborator	External contributors (e.g., consultants, contractors) with access to one or more repositories, but not full org membership.

Enterprise Permission Levels

Role	Description
Owner	Complete control of the enterprise. Can manage administrators, add/remove organizations, enforce policies, and manage billing.
Member	Same permissions as organization members.
Billing Manager	View and edit billing information, manage billing managers.
Guest Collaborator	Limited access to specific repositories/organizations (Enterprise Managed Users only).

Team Synchronization

If your company uses Microsoft Entra ID or Okta as an identity provider (IdP), you can manage GitHub team membership through team synchronization. With team sync enabled, GitHub automatically mirrors IdP group changes—removing the need for manual updates or custom scripts.

This centralized approach simplifies:

• Onboarding new employees
• Adjusting access when users move between teams
• Removing access when employees leave the organization

Requirement: Team sync requires your IdP admin to enable SAML SSO and SCIM provisioning.

Searching GitHub

• Global search:

  • Searches across all of GitHub.
  • Returns results from code, issues, PRs, users, Marketplace, etc.
  • Supports full search syntax (is:pr, is:issue, etc.), though not every filter works for every result type.

• Context search:

  • Scoped to the current repo and specific tab (Issues, PRs).
  • Exposes type-specific filters (author, labels, projects, etc.).
  • Best when searching inside a single repo.

• Common search filters:

  • is:open is:issue assignee:@me → Open issues assigned to me.
  • is:closed is:pr author:contoso → Closed PRs created by @contoso.
  • is:pr sidebar in:comments → PRs with “sidebar” in comments.
  • is:open is:issue label:bug -linked:pr → Open bug issues without a linked PR.

Organizing Work

• Milestones

  • Group issues/PRs into goals (sprints, releases, phases).
  • Track progress automatically (done vs remaining).
  • Search by milestone: is:open is:issue milestone:"Sprint 1".

• Labels

  • Metadata to classify issues/PRs (bug, priority, team).
  • Searchable with label:bug.

• Assignees

  • Assign issues/PRs to one or more people.
  • Searchable with assignee:@me.

Git History & Collaboration

• Git blame

  • Shows commit history for each line of a file.
  • Helps identify who changed what and when.
  • GitHub adds a UI view for easy navigation.

• Cross-linking

  • Link issues, commits, PRs, and projects to provide context.
  • Autolinks happen automatically with #123 or commit IDs.

• Saved replies

  • Prewritten responses for maintainers.
  • Great for common feedback (setup instructions, bug triage).

• Issue templates

  • Better than saved replies for collecting structured info up front.
  • Can define bug/feature request templates in repo settings.

• Mentions (@username)

  • Notifies specific users to join the discussion.
  • Keeps context even after issues are closed.