GitHub Foundations Certification Part -2

Sule Akturk

29 min read

·

Dec 22, 2025

--

Listen

Share

In the first part of this series, we covered the foundational tools and features that form the backbone of GitHub’s ecosystem, ranging from the basics of Git and GitHub to advanced tools like GitHub Copilot and GitHub Projects. In this second part, we are diving deeper into more advanced topics and best practices that will help you not only enhance your workflow but also contribute to and manage projects more effectively.

This section will cover essential areas like contributing to open-source projects, managing repositories securely, and administering GitHub environments. You will also learn about practical tools and strategies for maintaining a secure codebase, automating workflows, and even using GitHub in combination with Python through GitHub Copilot.

The topics for this section are organized as follows:

• Module 1: Contribute to an Open-Source Project on GitHub
• Module 2: Manage an InnerSource Program Using GitHub
• Module 3: Maintain a Secure Repository Using GitHub Best Practices
• Module 4: Introduction to GitHub Administration
• Module 5: Authenticate and Authorize User Identities on GitHub
• Module 6: Manage Repository Changes Using Pull Requests on GitHub
• Module 7: Search and Organize Repository History on GitHub
• Module 8: Using GitHub Copilot with Python

Module 1: Contribute to an Open-Source Project on GitHub

Getting involved in open source can feel intimidating at first — especially if you think it’s all about writing complex code.
The truth is, open source thrives on diversity — of skills, ideas, and perspectives.
Whether you’re a developer, designer, writer, or problem-solver, there’s a place for you to contribute and grow.

Here’s how to find where you can make the most impact.

1. Find What Inspires You

Before contributing, ask yourself: What kind of projects excite me?
Maybe it’s a library you use daily, a tool that simplifies your workflow, or a cause that aligns with your values.

When you choose something that genuinely interests you, learning and contributing feel natural — not like work.
Passion is what turns small contributions into meaningful change.

2. Discover the Right Projects

The open source world is huge — so start small.
Platforms like GitHub make it easy to discover projects looking for help.

Look for labels such as:

• good first issue — beginner-friendly tasks
• help wanted — contributions needed
• documentation — updates or improvements

You don’t need to write code from day one. Editing a README, clarifying setup steps, or organizing an issue list are all valuable contributions.

3. Explore Different Ways to Contribute

Open source is more than commits and pull requests — it’s collaboration in every form.
Here are some non-code ways to make an impact:

• Improve documentation: fix typos, add examples, or translate guides.
• Design and UX: suggest interface improvements or create visuals.
• Testing: report bugs, verify fixes, and share feedback.
• Community: answer questions, write tutorials, or help others get started.

Every role matters — projects grow when people share their unique skills.

4. Start Small, Learn, and Grow

No one begins as an expert contributor.
Your first pull request might fix a small typo — and that’s completely fine.
Each step helps you understand how the project works and builds trust with maintainers.

Over time, you’ll gain confidence, take on more complex issues, and maybe even mentor new contributors.
The key is consistency and curiosity — not perfection.

How to Contribute to an Open Source Repository

Once you’ve identified where to help in open source, the next challenge is how to make that contribution effectively. This stage is less about code — and more about communication, collaboration, and respect for process.

1. Communication Comes First

Before you write any code, talk to the maintainers.
Why? Because open source is teamwork.

If you start working without telling anyone, you might duplicate someone’s effort or build something that doesn’t fit the project’s goals. A short message can save hours of wasted time.

Always:

• Comment on an existing issue before you start.
• Or, open a new issue to propose your idea.
• Wait for confirmation before diving in.

Maintainers are usually volunteers — patience and kindness go a long way.

2. State Your Intent Clearly

If you want to fix a bug or add a feature, make your intentions public:

• Check if anyone’s already assigned to the issue.
• Leave a comment like:

“I’d like to work on this one — is it available?”

• If it’s a new idea, describe it briefly and ask for feedback.

This small step builds trust and shows that you’re collaborating, not just coding.

3. The Pull Request (PR) in a Nutshell

A pull request (PR) is how your work officially enters the project. It’s a space for:

• Your proposed changes (commits)
• A short explanation
• A public discussion about those changes
• Automated checks and code reviews

Basic flow:

1. Fork the project.
2. Clone it to your machine.
3. (Optionally) create a new branch.
4. Make and commit your changes.
5. Push your branch and open a pull request.

Each step makes your contribution visible and reviewable — two key traits of successful open source work.

4. Respect the Review Process

When you open a PR, it goes through automated status checks and code reviews.
If something fails, don’t panic — it’s normal.

Read the details, fix what’s needed, and push your updates. Your PR will update automatically.
If you’re unsure, politely ask for guidance in the comments — that’s what collaboration looks like.

5. Learn to Embrace Feedback

Feedback isn’t rejection — it’s mentorship.
Maintainers might request small revisions or ask for clarification. Use it as a chance to learn and improve.

If your PR is approved, congratulations — your code is now part of something bigger!
If it’s not, you still gained valuable experience and insight into the process.

6. Keep It Public, Respectful, and Patient

Good etiquette is essential:

• Always discuss issues publicly (no DMs or private messages).
• Be polite in every comment or reply.
• Understand that maintainers are people too — responses may take time.

Your professionalism leaves a lasting impression and builds your reputation in the open source world.

Recap

Here’s the open source contribution cycle in one line:

Communicate → Confirm → Contribute → Collaborate → Celebrate 🎉

By being open, patient, and respectful, your work not only strengthens the project — it strengthens you as a developer and community member.

Module 2: Manage an InnerSource Program Using GitHub

In the past, software development was divided into two models: open source (where anyone can contribute and access the code) and proprietary (which keeps the code private for competitive advantage).

However, some companies want the benefits of open-source practices — like transparency, external contributions, and bug tracking — without giving up their proprietary software. InnerSource is the solution, allowing companies to adopt open-source principles internally. By using platforms like GitHub, companies can encourage collaboration, improve discoverability, and streamline contributions, all while maintaining control over their intellectual property. This hybrid model brings the best of both worlds.

How to Manage a Successful InnerSource Program

InnerSource is the practice of applying open-source patterns to projects with a limited audience. For example, a company might establish an InnerSource program that mirrors the structure of a typical open-source project, except that it’s only accessible to the employees of that company. In effect, it’s an open-source program behind your company’s firewall.

An InnerSource program offers several benefits beyond traditional closed-source models:

1. Internal Visibility: Developers can access source code, issues, and project plans from other teams, which boosts productivity by allowing them to reuse code and better understand project progress and direction.
2. Reduced Friction: Teams can propose changes to other teams’ projects, like bug fixes or new features. If changes can’t be merged, they have the option to fork the project to meet their needs.
3. Standardized Practices: InnerSource helps standardize processes across teams, making it easier for developers to contribute to different projects even if teams have different workflows. It encourages consistency in how contributions and processes are managed.

Set up an InnerSource program on GitHub

GitHub repositories can be configured with three levels of visibility:

1. Public: Visible to everyone, suitable for open-source projects accessible both internally and externally.
2. Internal: Visible only to members of the enterprise that owns the repository, ideal for InnerSource projects within an organization. (Note: Available to GitHub Enterprise customers.)
3. Private: Visible only to the owner and those specifically granted access, suitable for projects with restricted access.

In addition to visibility, you can set permissions at the individual or team level, with five possible levels:

1. Read: For non-code contributors who want to view or discuss the project.
2. Triage: For contributors managing issues and pull requests without write access.
3. Write: For contributors who actively push to the project.
4. Maintain: For project managers who manage the repository but don’t perform sensitive actions.
5. Admin: For full access, including security management and repository deletion.

1. Make Repositories Discoverable

Use clear, descriptive repository names (e.g., warehouse-api, supply-chain-web)

Write a concise project description (1–2 sentences)

Add a license file to clarify usage rights

Include a README.md file:

• Explain the project’s purpose and goals
• Show examples or screenshots
• Link to live/demo versions if possible
• List prerequisites and setup instructions
• Reference dependencies on other projects

Use Markdown for formatting

• Place README in .github, root, or docs folder

2. Encourage Contributions

Create a CONTRIBUTING.md file:

• Explain how to submit bug reports, pull requests, etc.
• Outline contribution rules and coding standards

GitHub will link to this file when users create issues or PRs

Add a CODEOWNERS file:

• Define individuals or teams responsible for reviewing code

3. Use Templates for Consistency

Create issue templates: .github/ISSUE_TEMPLATE.md

• Pre-fill useful prompts (e.g., steps to reproduce a bug)

Create pull request templates: .github/PULL_REQUEST_TEMPLATE.md

• Guide users to include relevant info in PRs

4. Define Clear Workflows

Outline how to handle:

• Branching for features and bug fixes
• Pull request submission and review
• Release and deployment process

Communicate this clearly in the README or CONTRIBUTING file

Consider using GitHub Flow or similar for guidance

5. Track Success with Healthy Metrics

Focus on team-level, process-oriented metrics:

• Code review turnaround time
• Average pull request size
• Time from request to first response
• Number of active, unique contributors
• Number of projects reusing shared code
• Cross-team collaboration signals (e.g., @mentions)

Module 3: Maintain a Secure Repository Using GitHub Best Practices

Security in software development is no longer an afterthought — it’s a continuous practice that begins the moment you start writing code. A secure development strategy ensures your data, code, and workflows are protected at every step.

Shift Left: Security Starts Early

Security shouldn’t wait until deployment. The “shift left” approach means integrating security testing early in the development lifecycle — alongside coding, building, and reviewing. This allows teams to catch vulnerabilities sooner, reduce rework, and deliver safer software faster.

Build a Security-First Culture

Security is an evolving discipline. Developers and teams must keep learning about secure coding, threat modeling, and compliance. A culture of continuous security education helps prevent both mistakes and misunderstandings.

Essential GitHub Security Features

GitHub provides built-in tools that make securing your repositories easier:

• SECURITY.md — Communicate how to report vulnerabilities responsibly.
• Dependabot Alerts — Detect and fix vulnerable dependencies automatically.
• Security Advisories — Privately discuss and publish vulnerability fixes.
• Code Scanning — Find and resolve security issues directly in your code.
• Secret Scanning & Push Protection — Prevent accidental leaks of credentials and tokens.

Keep Sensitive Files Out

Use .gitignore to prevent committing private data or configuration files. Always assume that once data is committed, it’s potentially exposed — even if deleted later.

Enforce Secure Collaboration

Protect your critical branches with rules and reviews:

• Branch Protection Rules — Require builds, linting, or tests before merging.
• Required Reviewers — Ensure code is reviewed before changes go live.
• CODEOWNERS File — Assign ownership and accountability for specific parts of your codebase.

Key Takeaway

Security isn’t a single feature — it’s a mindset. By shifting left, automating checks, and using GitHub’s built-in tools, teams can make security a natural part of their everyday development flow.

Automating Security in GitHub: How to Protect Your Codebase with Minimal Effort

In today’s fast-paced software development environment, security is more crucial than ever. With countless external dependencies and the constant need to push new updates, it can be easy to overlook potential vulnerabilities. Fortunately, GitHub provides a suite of automated tools to help you ensure your repositories remain secure, without the manual overhead. In this article, we’ll explore the powerful automated security features GitHub offers, and how you can use them to protect your projects.

1. Detect and Fix Outdated Dependencies with Security Vulnerabilities

One of the most significant security risks in modern software projects is outdated dependencies. As your project grows, it becomes harder to track every package’s version and security status. Left unchecked, outdated dependencies can expose your project to known vulnerabilities. Fortunately, GitHub has several features that can help mitigate this risk, allowing you to keep your project safe without constantly monitoring every dependency.

Repository Dependency Graph

Press enter or click to view image in full size

Every GitHub repository comes with a dependency graph by default. GitHub scans the common package manifests in your project (such as package.json, requirements.txt, etc.) and creates a visual representation of your project’s dependencies. This makes it easier to track what your project relies on, and which dependencies might have security risks.

Dependabot Alerts

Press enter or click to view image in full size

Even with the dependency graph, it can still be overwhelming to keep track of security vulnerabilities across all of your dependencies. This is where Dependabot alerts come in. These alerts automatically monitor your dependency graph and cross-reference your project’s packages against known vulnerability lists. When a new risk is detected, you’ll receive an alert directly in your GitHub repository, helping you stay on top of potential threats.

Automated Dependency Updates with Dependabot

When a vulnerability is identified, your team typically needs to update the affected dependency. Instead of manually checking and updating versions, Dependabot automates this process. It creates pull requests with the updated versions, which can be reviewed and merged by your team. This ensures that your project always uses the latest secure versions of its dependencies, with minimal manual intervention.

2. Automated Code Scanning: Catching Vulnerabilities in Your Code

While dependencies are a common source of vulnerabilities, your actual code might also have security flaws. GitHub’s automated code scanning can help find these vulnerabilities, whether they’re new or old.

Why Code Scanning Matters

Code scanning lets you automatically scan your repository for security issues, errors, and potential vulnerabilities. It also helps you prioritize which issues to address first, ensuring that the most critical problems are handled promptly. GitHub integrates CodeQL, a query language that allows you to query your code as data, enabling you to detect vulnerabilities efficiently.

With code scanning, you can:

• Find and triage vulnerabilities before they become a serious issue.
• Prevent new vulnerabilities from entering the codebase by catching issues during development.
• Customize scans using queries created by both the GitHub team and the open-source community.

You can easily enable automated code scanning from the Security tab in your GitHub repository. Once activated, GitHub will run scans every time new code is pushed, keeping your repository secure and up to date.

3. Secret Scanning: Keeping Your Secrets Safe

Accidentally committing sensitive information — such as API keys, credentials, or other secrets — into your repository is a common mistake that can have serious security implications. Secret scanning helps mitigate this risk by automatically detecting secrets in your code.

How Secret Scanning Works

GitHub’s secret scanning feature automatically searches for known secrets in your repository’s code. This is especially important for public repositories, where anyone can view your code. When a secret is detected, GitHub notifies the service provider that issued the credential (e.g., AWS, Google Cloud, or Stripe), who can then take action to revoke the compromised secret or issue a new one.

By default, secret scanning is enabled for public repositories. For private repositories, repository administrators or organization owners can enable this feature as well. This proactive scanning can save you from costly breaches and secure your application’s integrity.

Conclusion: GitHub’s Automation Tools Are a Game-Changer for Security

GitHub’s suite of automated security features — such as Dependabot alerts, code scanning, and secret scanning — make it easier than ever to maintain a secure codebase. By leveraging these tools, you can detect and fix security vulnerabilities in both your dependencies and your own code with minimal effort. Best of all, these automated checks run in the background, freeing up your time to focus on what really matters: developing great software.

Module 4: Introduction to GitHub Administration

GitHub administration is the process of managing users, teams, and permissions within an organization to ensure smooth collaboration and strong security. The goal is to keep systems running efficiently while maintaining proper access control and structure.

GitHub administration operates across three main levels: team, organization, and enterprise.

1. Team-Level Administration

Teams represent smaller groups within an organization and often mirror the company’s internal structure. They allow more granular control over repository permissions and foster better communication between members.

At the team level, administrators can:

• Create, rename, or delete teams
• Add or remove members, or sync team membership with an Identity Provider (IdP) such as Microsoft Entra ID
• Manage outside collaborators (e.g., consultants or contractors)
• Enable or disable team discussions
• Set team visibility and profile images
• Configure automatic code review assignments and reminders

Best Practices:

• Build nested teams that reflect your company hierarchy.
• Create interest- or technology-based teams (e.g., JavaScript, Data Science) to streamline pull request reviews.
• Use IdP synchronization to automate onboarding, permission updates, and offboarding — reducing manual work and errors.

2. Organization-Level Administration

Organizations are shared spaces that enable users to collaborate across multiple projects at once. Owners and administrators have advanced control over user access, security, and overall structure.

At the organization level, owners can:

• Invite or remove members
• Create teams and assign team maintainers
• Manage outside collaborators and repository access levels
• Configure security and billing
• Use custom scripts for reporting or large-scale migrations

Recommendation:
Try to maintain a single organization for all users and repositories. Managing multiple organizations adds complexity, setup time, and potential for misconfiguration.

3. Enterprise-Level Administration

Enterprise accounts (GitHub Enterprise Cloud or Enterprise Server) allow centralized management of multiple organizations, policies, and billing structures.

Enterprise-level administrators can:

• Enable SAML (Security Assertion Markup Language) Single Sign-On (SSO) to link external IdP identities with GitHub accounts
• Add or remove organizations from the enterprise
• Manage central billing for all organizations
• Define enterprise-wide policies for repositories, projects, teams, and security
• Apply large-scale configuration changes or data migrations
• Integrate internal systems with GitHub.com using GitHub Connect

Understanding SAML, IdP, and SP

To better understand how authentication and access control work in GitHub Enterprise, let’s break down a few key terms:

🔸 SAML (Security Assertion Markup Language)

SAML is an XML-based standard used for securely sharing authentication and authorization data between two systems — usually an Identity Provider (IdP) and a Service Provider (SP).
It enables Single Sign-On (SSO) — letting users log in once and access multiple apps without re-entering their credentials.

🔸 Identity Provider (IdP)

An IdP is a system that verifies user identities. Examples include Microsoft Entra ID, Okta, or Google Workspace.
When a user logs in, the IdP authenticates them and sends a SAML assertion (a secure message confirming the user’s identity) to GitHub.

🔸 Service Provider (SP)

The SP is the application that the user wants to access — in this case, GitHub.
GitHub trusts the IdP’s authentication, receives the SAML assertion, and grants access to the user without requiring another login.

Press enter or click to view image in full size

In Summary

GitHub administration ensures efficient collaboration and security at every level:

• Team level — manage collaboration and permissions
• Organization level — control access, structure, and governance
• Enterprise level — enforce centralized security and integration policies

When managed effectively, GitHub becomes not just a development platform, but a cohesive ecosystem for collaboration, compliance, and innovation.

How GitHub Authentication Works: A Quick Guide for Teams and Admins

When managing a GitHub organization or enterprise, one of the most important administrative tasks is controlling how users authenticate to access your repositories. GitHub provides several secure authentication options — each designed for different use cases and security needs. Let’s break them down.

Authentication Options

1. Personal Access Tokens (PATs)

GitHub no longer supports passwords for Git or API operations. Instead, users can generate Personal Access Tokens as a more secure alternative.
Each token can be scoped to specific repositories or organizations, limiting access to only what’s necessary. When using the command line, users enter the token instead of a password.

2. SSH Keys

SSH keys are a secure and convenient way to authenticate without entering credentials every time.
Users generate an SSH key pair, add the public key to GitHub, and keep the private key on their machine. For organizations using SAML SSO, SSH certificates can also be used to streamline secure access.

3. Deploy Keys

Deploy keys are special SSH keys that grant access to a single repository — ideal for automated deployments or CI/CD systems.
The public key is added directly to the repository (not tied to a user account), and permissions can be configured as read-only or read-write.

Added Security Layers

4. Two-Factor Authentication (2FA)

To strengthen account security, GitHub supports multiple forms of 2FA, including:

• Authenticator apps (Google Authenticator, Authy, etc.)
• Hardware security keys (YubiKey, Titan)
• Passkeys (passwordless login)
• SMS codes (less secure, not recommended)

Organization and enterprise admins can enforce 2FA for all members and collaborators, reducing the risk of unauthorized access.

5. SAML Single Sign-On (SSO)

For enterprises using centralized identity management, SAML SSO lets users authenticate through an Identity Provider (IdP) like:

• Microsoft Entra ID (Azure AD)
• Okta
• OneLogin
• PingOne
• AD FS

This setup gives admins complete control over who can access repositories and resources while keeping credentials managed in one place.

6. LDAP Integration (GitHub Enterprise Server)

For on-premise environments, LDAP integration allows GitHub Enterprise Server to authenticate users directly against corporate directories such as:

• Active Directory
• OpenLDAP
• Oracle Directory Server

This ensures seamless access control using your existing enterprise identity systems.

Key Takeaway

GitHub offers flexible, layered authentication options that balance convenience and security.
From tokens and SSH keys to SAML and 2FA, admins can tailor authentication methods to their organization’s needs — keeping code, data, and users safe.

Pro Tip: Always enforce 2FA for all members and use tokens or SSH keys instead of passwords for Git operations.

Understanding GitHub Organizations and Permissions: The Complete Guide for Teams and Admins

As your development team grows, managing access and permissions on GitHub becomes essential. GitHub’s permission structure is designed to give the right people the right level of access — while keeping your repositories secure and well-organized.

Let’s break down how permissions work across repositories, teams, organizations, and enterprises.

Repository Permissions

Each GitHub repository has five standard permission levels, each granting progressively more control:

Press enter or click to view image in full size

Tip: Always apply the principle of least privilege — grant users only what they need to do their job.

Admins on GitHub Enterprise can also create custom roles by extending these base roles with specific permissions.

Forking Repositories

Forking allows users to create their own copy of a repository under their account.
It’s perfect for experimenting, contributing to open source, or making changes without affecting the original project.

Fork management options for admins:

• Public repositories: Always forkable.
• Private repositories: Forking can be disabled or limited to organization members.
• Internal repositories: Can only be forked within the same enterprise.

To update fork permissions:
Navigate to Settings → Member privileges → Repository forking in your organization dashboard.

Repository Insights

GitHub’s Insights tab gives valuable visibility into repository activity and health:

• Contributors: Track commits, additions, and deletions over time.
• Traffic: See visits, views, and referrers.
• Commits: Monitor commit frequency.
• Dependency Graph: Identify potential security vulnerabilities.

Use insights to monitor contributions, track engagement, and improve security.

Ways Users Get Repository Access

A user’s effective access is determined by the highest level of permission they receive through any of these methods:

Press enter or click to view image in full size

Auditing Access:

• Go to Settings → Manage Access to review users and teams.
• Use the Organization Audit Log or Enterprise Audit Log for deeper tracking.
• Automate monitoring with the GitHub REST or GraphQL API.

Team Permissions

Teams make permission management scalable and structured.
You can group users by department, project, or role — and assign permissions to the entire team at once.

Team members inherit access from their parent teams, allowing nested control.

Team Roles

Press enter or click to view image in full size

Maintainers can also:

• Add or remove team members
• Edit team details
• Manage code review assignments
• Control repository access for their team

Best Practices for GitHub Permission Management

1. Follow the Principle of Least Privilege — Avoid giving more access than necessary.
2. Audit Regularly — Check who has admin or write access to critical repositories.
3. Use Teams for Scalability — Manage groups, not individuals.
4. Enforce Branch Protections — Require reviews and CI checks before merging.
5. Monitor Activity — Use Insights and Audit Logs for transparency and security.

Takeaway

GitHub’s layered permission system — spanning repositories, teams, organizations, and enterprises — makes it easier to manage access at scale while maintaining tight security.
Whether you’re running an open-source project or managing hundreds of developers, understanding these controls ensures smooth collaboration and robust governance.

Pro Tip: Combine GitHub’s permissions with 2FA or SAML SSO for maximum protection and accountability across your organization.

Managing Enterprise Access, Permissions, and Governance on GitHub

As teams scale, managing access and governance across multiple repositories becomes critical. GitHub provides structured permission models to help enterprises balance collaboration, control, and security.

Organization Permissions

GitHub organizations centralize collaboration and define who can do what.

Main roles:

• Owner: Full control, including member management.
• Member: Can create and manage repositories and teams.
• Moderator: Manages discussions and contributor interactions.
• Billing Manager: Handles billing details.
• Security Manager: Oversees security alerts and policies.
• Outside Collaborator: Limited access to specific repositories.

Admins can set default member permissions, often giving read-only access by default and elevating privileges as needed.

Enterprise Permissions

At the enterprise level, administrators manage policies across multiple organizations.

Enterprise roles:

• Owner: Full administrative control and policy enforcement.
• Member: Standard collaboration rights.
• Billing Manager: Manages enterprise billing.
• Guest Collaborator: Limited access (for Managed Users).

Enterprises can also define default repository permissions and streamline governance through nested teams, automation, and auditing.

Structuring Your Enterprise

Single Organization: Easier to manage and consistent, but less flexible and riskier if compromised.
Multiple Organizations: More secure and customizable, but introduces complexity and administrative overhead.

Most large enterprises use multiple organizations for better isolation and scalability.

Default Read vs. Default Write

Press enter or click to view image in full size

Active Directory (AD) Sync & Automation

Syncing GitHub with Active Directory centralizes user management, automates onboarding, and ensures consistent roles.

Automation and scripting improve scalability — use modular, reusable code with logging, testing, and version control to keep permissions aligned across organizations.

Key Takeaway

Enterprise governance on GitHub is about balance: combine structured permissions, least-privilege access, AD integration, and automation to maintain both agility and control.

With the right setup, GitHub becomes a secure, scalable platform for enterprise collaboration.

Module 5: Authenticate and Authorize User Identities on GitHub

Authentication is the first gate to any secure development ecosystem — and in GitHub Enterprise, it’s the cornerstone of safeguarding your organization’s code, data, and workflows. Balancing usability with strong security practices ensures developers can move fast without compromising protection.

Modern Authentication in GitHub

GitHub offers several modern, secure authentication methods that integrate smoothly with enterprise identity systems:

• Passkeys & WebAuthn:
  Passwordless, phishing-resistant logins tied to a user’s physical device or biometric factors like fingerprint or face ID. These enhance both security and user experience.
• GitHub Mobile for 2FA:
  Push notifications enable quick, secure authentication without disrupting developer workflows.

OAuth and GitHub Apps

• OAuth Apps leverage GitHub’s OAuth 2.0 flow to grant scoped access to third-party applications.
• GitHub Apps authenticate at the installation level with fine-grained permissions — perfect for automation and CI/CD pipelines.

Enterprise Managed Users (EMU)

In GitHub Enterprise Cloud, EMUs enforce authentication only through your organization’s Identity Provider (IdP).
This ensures:

• Centralized identity control
• Enforced credential policies
• Strict access boundaries

SAML Single Sign-On (SSO)

SAML SSO is the backbone of enterprise-grade authentication. It connects your IdP (like Okta, Microsoft Entra ID, or PingOne) with GitHub, allowing users to sign in once across multiple services securely.
Admins can manage:

• Role-based access
• Activity monitoring and auditing
• Least-privilege permissioning

Access and Authorization Controls

GitHub’s layered authorization model helps enterprises enforce robust security policies:

• Fine-Grained Personal Access Tokens (PATs): Scoped, expirable, and auditable tokens replacing classic PATs.
• Custom Repository Roles: Enables tailored access and least-privilege configurations.
• Security Policies: Mandatory 2FA, IP allowlists, and OAuth app restrictions.

Organization and Enterprise Governance

Organization-level controls include default roles, team-based access, and the management of external collaborators.

Enterprise-level governance includes:

• Centralized SAML enforcement.
• IdP-based login restrictions.
• Global policy enforcement via GitHub Enterprise Cloud.

Press enter or click to view image in full size

User Authentication

When it comes to user authentication, security should be the number one consideration that comes to mind. Strong security is essential. It seems like every month or so, a company reports a data breach. Credentials are stolen because of inefficient security processes, or simply because of a lack of up-to-date security features within the company. Establishing secure user authentication can be a difficult task if user adoption requires long and frustrating steps to authenticate.

GitHub Enterprise supports two recommended methods for secure user authentication:

• SAML Single Sign-On(SSO)
• Two-Factor Authentication(2FA)

SAML Single Sign-On(SSO)

Press enter or click to view image in full size

GitHub removes only organization members who fail to authenticate. Enterprise members remain until they next access the resource.

Step-by-Step: Enabling and Enforcing SAML SSO

Press enter or click to view image in full size

Two-Factor Authentication (2FA)

2FA adds a second verification step beyond username and password. You can require 2FA for organization members, outside collaborators, and billing managers.

Press enter or click to view image in full size

User Authorization in GitHub Enterprise

After users authenticate through your Identity Provider (IdP) with SAML Single Sign-On (SSO), the next layer of protection is authorization — deciding what those users (and their tools) can access within your organization.

From Authentication to Authorization

While authentication verifies who a user is, authorization defines what they can do.
In GitHub, this means granting access to organization resources through secure tools such as:

• Personal Access Tokens (PATs)
• SSH Keys
• OAuth Apps

Security Assertion Markup Language (SAML) Single Sign-On (SSO) enables enterprise and organization owners to centrally control and manage user access to GitHub resources such as repositories, issues, pull requests, and other collaboration tools.

Automating Authorization with SAML SSO + SCIM

To streamline and secure access control, GitHub Enterprise supports integration between SAML SSO and SCIM (System for Cross-domain Identity Management).

Press enter or click to view image in full size

Why It Matters

Integrating SCIM with SAML SSO ensures:

• Automatic onboarding of new employees
• Automatic removal of departing users
• Reduced manual errors and overhead
• Immediate token revocation, minimizing security risk

Without SCIM, enterprise admins must manually manage user removal and token cleanup — a time-consuming and error-prone process.

Managing SSH Keys and Personal Access Tokens (PATs) with SAML SSO in GitHub Enterprise

In an enterprise environment, managing identities and credentials isn’t just about signing in — it’s about ensuring that every key, token, and permission reflects your organization’s identity and access policies.
That’s where SAML SSO and SCIM come together to automate and secure GitHub access across users, systems, and integrations.

Credential Management: SSH Keys and PATs

Even with centralized SSO, developers and systems still rely on Personal Access Tokens (PATs) and SSH keys to connect securely to GitHub APIs or Git operations.

• These credentials are authorized and auditable, and each is securely linked to a verified SAML SSO identity.
• Admins can review, revoke, or rotate these credentials anytime through organization security settings.
• For onboarding, new users can register via:
  👉 https://github.com/orgs/ORGANIZATION/sso/sign_up
  This link can be displayed in your IdP dashboard to simplify user setup.

SCIM Integration with GitHub Enterprise Cloud

SCIM simplifies identity management by supporting both native and custom integrations.

Supported Providers

• Okta
• Microsoft Entra ID
• OneLogin
• Ping Identity
• Google Workspace

These providers offer native GitHub integration, ensuring reliable provisioning and minimal setup effort.

Custom SCIM Integrations

If your IdP isn’t natively supported, GitHub’s SCIM 2.0 API lets you build your own integration.
For example:

Press enter or click to view image in full size

SCIM vs. Manual User Management

Press enter or click to view image in full size

Comparing IdP Integration Paths

Press enter or click to view image in full size

GitHub Membership Considerations

Press enter or click to view image in full size

Team Synchronization in GitHub Enterprise: Automating Access the Smart Way

Managing user and team access across large development organizations can quickly become messy — especially when headcount and roles are constantly changing.
GitHub’s Team Synchronization feature bridges this gap by connecting your Identity Provider (IdP), like Microsoft Entra ID (Azure AD) or Okta, directly with your GitHub teams.

When enabled, team sync automatically updates GitHub team memberships based on group changes in your IdP — eliminating manual updates, scripts, and the risk of access drift.

Team Synchronization vs. SCIM for GHES

In GitHub Enterprise Server (GHES), managing user access and team memberships can be achieved through various methods, including team synchronization and System for Cross-domain Identity Management (SCIM). Understanding these methods is essential for effective administration.

What Team Synchronization Does

Press enter or click to view image in full size

Team Sync doesn’t create new GitHub accounts — users must already be organization members.

Differences Between Team Sync and Group SCIM

Press enter or click to view image in full size

Enabling and Managing Team Synchronization

To enable:

1. Ensure SAML SSO and SCIM are active in your IdP.
2. Map GitHub teams to IdP groups via the GitHub UI or API.
3. Group membership changes in your IdP will sync automatically.

Supported IdPs:

• Microsoft Entra ID (Azure AD)
• Okta

Okta Requirements: SAML SSO, SCIM, tenant URL, and an SSWS token with read-only admin access.

Team Sync Usage Limits

Press enter or click to view image in full size

Choosing the Right Approach

Press enter or click to view image in full size

Module 6: Manage Repository Changes Using Pull Requests on GitHub

In GitHub, branches are isolated workspaces where developers can make changes without affecting the main project. They allow you to work on features, fix bugs, or experiment safely. However, at some point, these separate branches need to be combined into a common branch, typically the main branch. This is where pull requests (PRs) come in.

A pull request is a way to propose changes from one branch into another while allowing for review and discussion. It compares two branches:

• Compare branch: The branch containing the changes made by the developer.
• Base branch: The branch where the changes are intended to be merged, usually main.

Pull requests serve as a tool for collaboration, letting team members review code, leave comments, and ensure high-quality updates before merging.

Merging Pull Requests

GitHub provides multiple merge options:

• Merge commit: Combines all commits while keeping individual commit history.
• Squash and merge: Combines all commits into a single commit for a cleaner history.
• Rebase and merge: Reapplies commits on top of the base branch, creating a linear history without a merge commit.

After merging, the compare branch can be deleted to keep the repository organized.

GitHub Pull Request Merge Options

Branches Setup

main: A — -B — -E
feature: C — -D

• main = base branch
• feature = compare branch
• A, B, E = commits on main
• C, D = commits on feature

Merge Commit

• Combines all feature branch commits into main.
• Keeps all individual commits + adds a merge commit.

main: A — -B — -E — — — — -M
feature: C — -D /

• M = merge commit
• History shows all commits and the merge itself.

Squash and Merge

• Combines all feature branch commits into one commit before merging.
• Keeps history clean, no clutter from multiple small commits.

main: A — -B — -E — -S
feature: C — -D

• S = single squash commit

Rebase and Merge

• Reapplies feature commits on top of main.
• Maintains linear history, no merge commit.

main: A — -B — -E — -C’ — -D’
feature: C — -D

• C’ and D’ = new commits with same changes
• Clean, sequential history for easier tracking.

Advanced Features

• Requesting reviewers: Assign specific collaborators to review the PR.
• Branch protection rules: Some repositories require approvals, passing CI checks, or other conditions before merging.
• Status checks/CI: Automated tests or checks may run on PRs to ensure quality and security.

Module 7: Search and Organize Repository History on GitHub

Searching the Repository

Global Search:

• Searches all of GitHub (repositories, issues, PRs, users, Marketplace).
• Use advanced search syntax for precise queries.
• Example: sidebar repo:myorg/myrepo → finds “sidebar” mentions in a specific repo.

Context Search:

• Scoped to a specific tab (Issues, Pull Requests, Code).
• Provides type-specific filters: author, labels, projects, etc.
• Preferred for repository-specific queries.

Press enter or click to view image in full size

Using Milestones

Group issues and PRs into shared goals (sprints, releases, phases).

Track progress automatically (X of Y issues complete).

Creating Milestone:

• Go to Issues → Milestones → New milestone
• Add title, description, optional due date
• Assign milestone to issues or PRs

Search Example: is:open is:pr milestone:”Release v1.0"

Using Labels

• Metadata for categorizing issues/PRs (bug, feature, priority).
• Example filter: is:open is:issue label:bug
• Combine with other filters: is:pr label:”ready for review” author:@me

Using Git Blame

• Shows who changed what and when in a file.
• Helps find the right contributor to consult for a bug or feature.
• GitHub extends this with a user-friendly interface.

Cross-Linking

• Link issues, commits, PRs for better context.
• Autolink syntax: Duplicate of #8 automatically links issue #8.
• Commits auto-link with first 7+ characters of ID.

Saved Replies

• Prewritten comments for consistent responses.
• Useful for maintainers: FAQ answers, instructions.
• Can be inserted during issue or PR discussion.

Issue Templates

• Structured forms for new issues (bug reports, feature requests).
• Ensure contributors provide all necessary info upfront.
• Better than saved replies for collecting structured info.

Assignees

• Assign one or more users to indicate responsibility
• Use assignee: filter in searches: is:open is:issue assignee:@me.

Module 8: Using GitHub Copilot with Python

GitHub Copilot is an AI-powered coding assistant integrated into your IDE, designed to help developers write code faster and more efficiently. It generates code suggestions based on natural language prompts, allowing you to quickly implement functions, syntax, or entire blocks of code without constantly referring to documentation.

How It Works:

• Natural Language Prompts: You type a comment or instruction (e.g., # Create a web API using FastAPI), and Copilot generates corresponding code.
• Context-Aware: Copilot understands your code context and offers relevant suggestions.
• Suggestions: Code suggestions appear in gray. You can accept them by pressing Tab or cycle through multiple options with Ctrl + Enter.

Key Benefits:

• Boosts Productivity: Reduces time spent on boilerplate code and syntax, letting you focus on complex tasks.
• Improves Code Quality: Suggests clean, efficient, and consistent code based on best practices.
• Multi-Language Support: Works with Python, JavaScript, Go, Ruby, and more, along with various frameworks like FastAPI, Django, and React.
• Assists with Documentation: Helps generate docstrings and comments, keeping your code well-documented.
• Learn New Tools: Copilot aids in exploring and working with unfamiliar libraries or frameworks by suggesting relevant code snippets.

In short, GitHub Copilot accelerates your development process, making coding smarter and faster by generating useful code suggestions directly within your IDE.

Using GitHub Copilot with Python

GitHub Copilot isn’t just useful when starting a new project — it can also help you maintain and enhance existing codebases. Whether you’re fixing bugs, adding features, or refactoring code, Copilot and GitHub Copilot Chat can make development faster and smoother by assisting directly within your coding environment.

Developing with GitHub Copilot

As projects evolve, developers need to keep their code updated, efficient, and functional. GitHub Copilot helps by suggesting relevant code snippets, testing ideas, and even generating new functionality. With GitHub Copilot Chat, you can ask natural language questions about your code and get clear, context-aware answers right in your IDE.

Prompt Engineering

To get the best results from Copilot, crafting effective prompts is essential. A prompt is an instruction or comment that tells Copilot what you want it to do. The quality and clarity of your prompt directly impact the accuracy of Copilot’s output.

For example:

# Create an API endpoint

This prompt is vague and could produce unpredictable results. A better prompt is:

# Create an API endpoint using the FastAPI framework that accepts a JSON payload in a POST request

This version is specific, giving Copilot clear direction and context. You can also provide additional details using comments, code examples, or Copilot Chat for richer suggestions.

Best Practices for Using Copilot

To get the most from GitHub Copilot, follow these best practices:

1. Start simple — Begin with a short prompt, then refine or expand it as needed.

Example:

• Start with: create an HTML form with a text field and button
• Then expand: add an event listener to send a POST request to /generate and display the response in a div with id “result”.

2. Cycle through suggestions — Use Ctrl + Enter (or Cmd + Enter on Mac) to view multiple suggestions and choose the best one.

3. Reword or guide Copilot — If suggestions aren’t accurate, tweak your prompt or start typing code to let Copilot autocomplete intelligently.

4. Use context effectively — Copilot considers open files in your editor when generating suggestions. To include other files or project-wide context, open them in your IDE or use @workspace in Copilot Chat.

Final Thoughts

With the completion of these eight modules, this second part concludes my GitHub Foundations Certification notes. In this section, we explored more advanced and practical topics, such as contributing to open-source projects, managing InnerSource programs, securing repositories, administering GitHub environments, and collaborating effectively through pull requests. We also looked into identity management, repository history, and using GitHub Copilot with Python to improve developer productivity.

Preparing for this certification helped me better understand not only GitHub’s features but also the best practices behind collaboration, security, and maintainability in real-world projects. The exam focuses heavily on concepts and workflows that are commonly used in modern software development teams, making it a valuable learning experience even beyond the certification itself.

I hope these notes help you feel more confident while preparing for the GitHub Foundations exam or while working with GitHub in your daily projects. Whether you are just starting out or looking to strengthen your foundational knowledge, mastering these topics will make your GitHub experience much more effective.

If you found this article helpful, feel free to clap, leave a comment, or share your own exam experience. Good luck with your GitHub Foundations journey — and happy coding! 🚀

Resources