Skip to main content Skip to local navigation
UIT

GitHub

GitHub is a cloud-based version control and collaboration platform used in software development, research, and teaching. All York faculty and staff get automatic access through York's GitHub Enterprise, where you can store code, track changes, collaborate on projects, and contribute to York's developer communities.

Access GitHub >>
Request a GitHub Org >>
Submit a Service Request

Featured Services

Overview

All York University faculty and staff are given automatic access to GitHub Enterprise, which enables:

  • Integrated Collaboration Tools: Share, review, and track code changes efficiently through pull requests and customizable workflows. Use a wiki to store your documentation alongside code.
  • Integrated Tracking Tools: Use GitHub Issues and Projects to plan work with features like kanban boards.
  • Centralized Administration: Manage multiple GitHub organizations from a single enterprise account, with unified policy enforcement and auditing capabilities

Your access level depends on your role:

  • Add, modify, and remove users from your organization
  • Enable GitHub Actions for organization members
  • Request and grant GitHub Copilot access to team members
  • Manage overall organization settings and policies
  • Access repositories and content shared by your organization owner
  • Collaborate on projects and contribute code

How do I access it?

Step 1: Sign in through York's SSO portal at https://github.com/enterprises/YorkUCA/sso using your Passport York credentials. You'll be redirected here automatically if you navigate to any York GitHub page while signed out.

Step 2: Join or create a GitHub organization. You'll need to be a member of an organization to collaborate on repositories and projects. Ask your manager to add you to your organization. If an organization doesn't already exist for your team, any manager can request one

External collaborators: Only users with a York account can access GitHub Enterprise. If you need to add external contributors who don't have York credentials, they'll need a PY account. Contact UIT to arrange this.

Jump to GitHub FAQs for sign-in details and troubleshooting

Frequently Asked Questions

GitHub FAQs

New to GitHub? Start with Microsoft's free beginner module: Introduction to GitHub (Microsoft Learn).

Ready to go further? Try these intermediate resources:

LinkedIn Learning also offers a wide selection of GitHub courses, including a beginner-friendly Learning GitHub course.

Sign in through York's SSO portal at https://github.com/enterprises/YorkUCA/sso using your Passport York credentials. This is the easiest way to access GitHub.

We recommend using the York SSO link. However, if you go to github.com/login directly, enter your username in this format: your Active Directory (AD) username followed by _yorkuca.

Example: If your AD username is johnsmith, enter johnsmith_yorkuca.

If your AD username contains an underscore: Replace the underscore with a hyphen before adding _yorkuca. For example, john_smith becomes john-smith_yorkuca.

To avoid confusion, use the York SSO link: https://github.com/enterprises/YorkUCA/sso.

Once signed in, you'll need to be a member of a GitHub organization to work with repositories and collaborate with others.

  • Creating a new organization: Any manager can approve this. Fill out the GitHub Request an Organization form to get started.
  • Joining an existing organization: Ask your organization owner to add you as a member.

Set up GitHub in Visual Studio Code

Only users with a York account can access GitHub Enterprise. External collaborators without York credentials need a PY (Passport York) account before they can be added. Contact askIT@yorku.ca to request a PY account for an external member.

The base GitHub Enterprise license is included for all York faculty and staff at no additional cost. However, some features require an Azure subscription and a department budget number:

  • Coming Soon: GitHub Actions (advanced CI/CD beyond included usage)
  • Coming Soon: GitHub Copilot (AI-assisted coding)

Speak to your manager about requesting access to these features.

The following paid features are currently not enabled, but may be made available at a future date:

  • Codespaces
  • Packages
  • Git LFS
  • Advanced Security

See our Storage Finder for data governance and compliance guidelines.

New to GitHub? Start here. These definitions explain core concepts you'll encounter when working with GitHub Enterprise at York.

Organization (Org)

What it is: A container for teams, repositories, and policies. Think of it as a workspace for a department, project, or research group.

Why it matters: Your organization is where you store code, manage team members, enable features like GitHub Actions and Copilot, and set access rules. At York, each department, lab, or project team typically has its own organization.

Key roles in an organization:

  • Owner: Full control. Can add members, enable features, delete repos, manage billing.
  • Member: Can access repos and contribute to code, but cannot add users or change org settings.

How organizations are created at York:

Organizations are created based on existing IT groups and department structures, including:

  • PMO (Project Management Office)
  • EABA (Enterprise Architecture and Business Analysis)
  • Faculty departments
  • Research centres and labs
  • Administrative units
  • Project teams

Organization owners are typically the managers or directors of those departments or groups. If you're a manager or director and your department needs a GitHub organization, contact UIT to have one provisioned.

Repository (Repo)

What it is: A folder that contains your project code, documentation, and version history. Every change is tracked.

Why it matters: Repos let you store code safely, see who changed what and when, and collaborate without overwriting each other's work. You might have multiple repos in one organization—one for each project or application.

Example: Your department might have one repo for a data analysis tool, another for website code, and a third for documentation.

Repo visibility: Only members you invite can see or access it.

Learn more: https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories

Branch

What it is: A separate copy of your code where you can make changes without affecting the main version.

Why it matters: Branches let team members work on different features at the same time. The main branch (usually called main) is the stable, production-ready version. You create branches to experiment, add features, or fix bugs.

Workflow: Create a branch → make changes → test → submit for review → merge back to main.

Learn more: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches

Commit

What it is: A snapshot of your code changes at a specific moment, with a message describing what changed and why.

Why it matters: Commits create a detailed history of your project. If something breaks, you can see exactly what changed, who changed it, and when. Each commit has a unique ID so you can reference or revert to it.

Example commit message: "Fixed login validation bug in auth module" or "Updated API endpoint for user data retrieval".

Learn more: https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/about-commits

Pull Request (PR)

What it is: A proposal to merge changes from one branch into another, typically from a feature branch into the main branch.

Why it matters: Pull requests let team members review code before it goes live. You describe what you changed and why, teammates comment and suggest improvements, and once approved, the changes merge automatically.

Workflow: Push your branch → open a PR → team reviews → address feedback → merge.

Learn more: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests

Issue

What it is: A task, bug report, feature request, or discussion tied to a repository.

Why it matters: Issues help teams track work and communicate about problems. You can assign issues to team members, add labels (like "urgent" or "documentation"), and link them to pull requests.

Examples:

  • "Login button not working on mobile devices"
  • "Add dark mode support to dashboard"
  • "Update API documentation for new endpoints"

Learn more: https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues

Merge

What it is: The action of combining code from one branch into another.

Why it matters: Merging is how changes move from a feature branch back to the main branch. GitHub can automatically merge pull requests once they're approved and pass tests.

Merge conflicts: When two people change the same line of code, Git can't decide which version to use. The person merging must resolve these conflicts manually.

Learn more: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request

Clone

What it is: Downloading a full copy of a repository (including all branches and history) to your local computer.

Why it matters: Cloning lets you work on code offline, make changes, test locally, and then push updates back to GitHub.

Command: git clone [repository URL]

Learn more: https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository

Push

What it is: Uploading your local changes to GitHub.

Why it matters: After you commit changes on your computer, you push them to make them visible to your team.

Command: git push

Learn more: https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository

Pull

What it is: Downloading the latest changes from GitHub to your local computer.

Why it matters: Before starting work, you pull to make sure you have the newest code from your team.

Command: git pull

Learn more: https://docs.github.com/en/get-started/using-git/getting-changes-from-a-remote-repository

Collaborator

What it is: A person with access to a repository who can make changes, review code, and contribute to the project.

Why it matters: You invite collaborators to repos so the right people can work on the right projects. You control what each person can do (view only, edit, admin).

Permission levels:

  • Pull: Can view and clone but not push changes.
  • Push: Can view, clone, and push changes.
  • Admin: Can manage settings, add collaborators, and delete the repo.

Learn more: https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository

Code Review

What it is: The process of examining code changes before they're merged, looking for bugs, improvements, or security issues.

Why it matters: Code reviews catch problems early, share knowledge across the team, and maintain code quality. It's a standard practice at most organizations.

Process: Someone submits a PR → reviewers comment → author makes changes → reviewers approve → changes merge.

Learn more: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews

Workflow / Git Workflow

What it is: A standardized process for how your team uses Git and GitHub—how you create branches, name them, submit PRs, and merge code.

Why it matters: Workflows keep teams organized and prevent chaos. Common workflows include "GitHub Flow" (simple, good for continuous deployment) and "Git Flow" (complex, good for multiple releases).

Typical York workflow: Create feature branch → make changes → submit PR → team reviews → merge to main.

Learn more: https://docs.github.com/en/get-started/quickstart/github-flow

README

What it is: A markdown file (README.md) at the root of a repository that explains what the project is, how to set it up, and how to use it.

Why it matters: READMEs are the first thing people see. A good README tells new team members and external developers how to get started quickly.

What to include:

  • Project description
  • Installation instructions
  • How to run or deploy
  • How to contribute
  • Contact or support information

Learn more: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes

.gitignore

What it is: A file that tells Git which files and folders to ignore (not track or upload).

Why it matters: You don't want to push sensitive files (passwords, API keys, local config files) or build artifacts to GitHub. .gitignore prevents accidental uploads.

Examples of what to ignore:

  • API keys and secrets
  • Database credentials
  • Local configuration files
  • node_modules/ (dependencies)
  • .env files

Learn more: https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files

Need Help?

Can't find what you're looking for? We're here to help.

Contact Us
Visit Us
Submit a Service Request