Skip to main content

GitHub guide

GitHub for beginners: what it is and how to use it

GitHub is where tech teams store and collaborate on code. Even PMs, BAs, and UX designers need to understand it. Here are the essentials.

What is GitHub?

GitHub is a website where developers store code and collaborate. It uses Git — a system that tracks every change to a file and lets teams merge work without overwriting each other.

Think of Git as the underlying version-control engine running on your computer, and GitHub as the cloud platform built on top of it where teams share, review, and discuss code. Nearly every tech company — from two-person startups to companies with thousands of engineers — uses GitHub or a close equivalent. Non-technical roles who understand it move faster, communicate more precisely, and earn more trust from engineering teams.

Key concepts

Six terms you will encounter on day one.

Repository (repo)

A project folder for code

A repository is where all the files for a project live — code, configuration, documentation, and history. Think of it like a Google Drive folder, except every change ever made is tracked. A company might have hundreds of repos: one for the mobile app, one for the backend, one for the marketing site.

Commit

A saved version of changes

A commit is like clicking Save, but with a label attached. Every commit records who made the change, when, and why (via a commit message). Developers commit dozens of times a day. The commit history is a full audit log of every change to the codebase — you can see exactly what was changed, by whom, and read the reason in the message.

Branch

A parallel version where work happens safely

A branch is a copy of the code where a developer can make changes without affecting the main codebase. Feature branches are named for the work being done — 'add-user-login' or 'fix-checkout-bug'. This means multiple engineers can work on different things at the same time without overwriting each other's work.

Pull Request (PR)

A request to merge a branch into the main code

When a developer finishes their work on a branch, they open a Pull Request asking to merge those changes into the main codebase. PRs are where code review happens: teammates leave comments, request changes, and eventually approve the work. As a PM or BA, PRs are where you can see exactly what is being shipped before it goes live.

Issue

A task, bug, or feature request

GitHub Issues are the built-in task tracker. An issue can represent a bug, a new feature request, a question, or a documentation task. Many small-to-mid-size teams use GitHub Issues instead of Jira — especially startups. Issues can be assigned to team members, labeled, linked to PRs, and organized into project boards.

README

The landing page of a repo

Every repo should have a README.md file at the root. When you visit a repo on GitHub, the README is what you see first — it explains what the project does, how to set it up, and how to contribute. A good README is what separates a project that looks professional from one that looks abandoned.

What non-developers need to know

You do not need to write code to use GitHub effectively. Here is how each non-technical role uses it on real teams.

Product Managers

Read Issues and PRs to understand what is being built and why. Comment on feature specs linked in Issues. Use GitHub Projects (the built-in kanban board) to track progress without needing a separate Jira instance. When a developer says 'the PR is up,' find it and read the description — it tells you exactly what changed.

Business Analysts

Create and manage GitHub Issues for requirements. Write acceptance criteria in the Issue body so engineers have clear definitions of done. Use labels to categorize issues by type (feature, bug, chore) and milestone to group work by release. GitHub Projects gives you a kanban view with no additional tools required.

UX Designers

Share design files and assets via GitHub — either as direct file uploads or links to Figma in the Issue. Understand branches so you know which designs are going into which version. When a developer opens a PR for your feature, check the description and screenshots to confirm the implementation matches the design before it is merged.

QA Engineers

Read PR descriptions before testing to understand exactly what changed. File bug reports as Issues with clear steps to reproduce, expected behavior, and actual behavior. Link your bug Issue to the PR that introduced the problem. Use labels like 'bug,' 'severity:high,' and 'regression' to help the team triage the backlog.

5 things to do this week on GitHub

You can complete all five of these in under an hour. Start today.

  1. 1

    Create a free account at github.com

    Sign up with your email — it takes two minutes. Your GitHub username is part of your professional identity in tech. Choose something professional: first name + last name or first initial + last name works well. This profile will be linked on your resume.

  2. 2

    Create your first repository

    Click the '+' icon in the top right and choose 'New repository.' Name it 'portfolio' or 'learning.' Set it to Public so employers can see it. Check the box to initialize it with a README. You now have your first repo.

  3. 3

    Write a README for it

    Edit the README.md file GitHub created for you. Introduce yourself, describe what you are learning, and list your career target. Use markdown headings (## About Me, ## What I am Learning). A clear README signals that you understand how real projects are documented.

  4. 4

    Browse an open-source project in your target domain

    Search GitHub for a tool you use or a company you admire. Open their Issues tab and read through the open issues. You will see how product problems are described, how bugs are reported, and how teams discuss requirements — all public and free to study.

  5. 5

    Star 5 repos relevant to your career track

    Stars are how you bookmark repos on GitHub. Starring repos in your target domain — SQL tools for data analysts, design systems for UX designers, PM frameworks for product managers — builds a list of resources and signals to your network what you are interested in.

GitHub for your portfolio

Public repositories show that you can work in tech workflows even before your first job. A GitHub profile with active repos signals initiative, comfort with professional tooling, and willingness to learn in public — all qualities hiring managers look for in career changers.

Add your case studies, SQL queries, or design docs as markdown files in a portfolio repo. A BA can upload requirements documents. A data analyst can push SQL scripts. A UX designer can link Figma files and write design rationale in markdown. You do not need to write code — you need to show that you understand version-controlled, collaborative work.

Link your GitHub profile on your LinkedIn and resume. Hiring managers at tech companies check it. Even a single well-documented repo is more convincing than saying "I am comfortable with technical tools" in an interview.

Keep going

Back to your career track

GitHub is one tool in a broader tech skill set. Browse role-specific learning paths to build the full picture — free to start, no coding required.

Back to your career track