Before touching any command, you need to understand what Git and GitHub actually are, and how they relate to each other.

Git is a free, open-source tool that tracks changes to files over time, allowing you to see the full history of a project, undo mistakes, and work on different versions of the same code without losing anything.

GitHub is a website and platform that hosts Git repositories online, adding features like collaboration tools, issue tracking, and a visual interface on top of what Git does on its own.

Git is the actual version control software that runs on your computer, while GitHub is an online service that hosts your Git repositories and adds collaboration features — you can use Git without GitHub, but GitHub relies on Git underneath.

A version control system is any tool that records changes to files over time, so you can review history, compare versions, and revert to an earlier state if something goes wrong — Git is the most widely used example.

A repository (often shortened to “repo”) is a project’s folder along with its entire tracked history — all the files, changes, and versions belonging to one project live inside a repository.

An open-source project has its code publicly visible and often available for anyone to use, modify, or contribute to, which is one of the main reasons GitHub has become the central hub for open-source software.

These are the handful of concepts that everything else in Git and GitHub is built around.

A commit is a saved snapshot of your project’s files at a specific point in time, along with a message describing what changed — commits are the individual building blocks of a project’s history.

A branch is an independent line of development within a repository, letting you work on new changes without affecting the main, stable version of the project until you’re ready to bring them together.

The main branch (historically called “master”) is typically the default, primary branch of a repository, usually representing the current stable or production-ready version of the project.

The working directory is the actual folder on your computer where you edit files directly — changes here aren’t tracked by Git until you explicitly tell it to.

The staging area is a holding zone where you place changes you intend to include in your next commit, letting you choose exactly which changes to save rather than committing everything at once.

The .git folder is a hidden folder Git creates inside your project that stores the entire history and configuration of the repository — deleting it would remove all of Git’s tracked history for that project.

flowchart LR
    A["Working Directory
(edit files)"] -->|git add| B["Staging Area
(ready to save)"]
    B -->|git commit| C["Repository History
(saved snapshot)"]
    

These are the handful of commands you’ll type constantly once you start using Git day to day.

git init turns an ordinary folder into a Git repository, creating the hidden .git folder needed to start tracking changes in that project.

git clone downloads a complete copy of an existing repository (including its full history) from somewhere like GitHub onto your own computer.

git add moves changes from your working directory into the staging area, marking them as ready to be included in your next commit.

git commit saves everything currently in the staging area as a new permanent snapshot in the repository’s history, along with a message describing the change.

git push uploads your local commits to a remote repository (like one hosted on GitHub), making your changes visible and available to others.

git pull downloads and merges changes from a remote repository into your local copy, keeping your local project up to date with what others have pushed.

git status shows you the current state of your working directory and staging area — which files have been changed, which are staged, and which aren’t yet tracked.

Once a repository lives on GitHub, a handful of special files and settings come into play.

A README is typically the first file people see when visiting a repository, usually explaining what the project does, how to install it, and how to use it.

A .gitignore file lists files and folders that Git should intentionally never track, such as temporary files, personal settings, or sensitive credentials that shouldn’t be shared.

A license file specifies the legal terms under which others are allowed to use, modify, or distribute a project’s code, which is especially important for open-source repositories.

A public repository can be viewed by anyone on the internet, while a private repository is only visible to people you’ve explicitly granted access to.

A fork is your own personal copy of someone else’s repository, created on GitHub, letting you freely experiment or make changes without affecting the original project.

Starring a repository is a simple way to bookmark it for later or show appreciation for the project, and starred repositories are easy to find again from your own GitHub profile.

Watching a repository subscribes you to notifications about its activity, such as new issues or pull requests, keeping you updated without needing to check the repository manually.

GitHub’s biggest strength is collaboration — here’s the vocabulary for working with other people on the same project.

A pull request is a formal proposal to merge changes from one branch into another, giving others a chance to review, comment on, and discuss the changes before they become part of the main project.

Merging combines the changes from one branch into another, integrating completed work (often from a pull request) back into the main line of development.

A merge conflict happens when Git can’t automatically combine changes because two branches modified the exact same part of a file differently, requiring a person to manually decide which change to keep.

An issue is a tracked item on GitHub used to report bugs, request features, or discuss tasks related to a project, serving as a to-do list and discussion thread combined.

Code review is the process of other contributors examining proposed changes (usually within a pull request) before they’re merged, catching mistakes and suggesting improvements.

A contributor is anyone who has submitted changes to a project, whether that’s code, documentation, or other improvements, typically through a pull request.

Branches are how multiple lines of work happen at once without interfering with each other — here’s the beginner vocabulary.

A branching strategy is simply an agreed-upon way a team organizes its branches — for example, keeping the main branch always stable and creating new branches for every new piece of work.

A feature branch is a branch created specifically to develop one new feature or fix, kept separate from the main branch until the work is complete and ready to be merged.

Checking out a branch switches your working directory to reflect that branch’s version of the files, letting you move between different lines of work.

Branch protection is a repository setting that prevents direct changes to an important branch (like main) without going through a pull request and review process first, helping maintain code quality.

Beyond just hosting code, GitHub offers a set of built-in tools worth knowing about early on.

GitHub Actions lets you automate tasks — like running tests or deploying code — automatically whenever something happens in your repository, such as a new commit being pushed.

GitHub Pages lets you host a simple website directly from a GitHub repository for free, commonly used for project documentation, portfolios, or personal blogs.

Discussions provide a forum-style space attached to a repository for open-ended conversations, questions, and community engagement, separate from the more task-focused issue tracker.

An organization is a shared account that groups repositories and members together, typically used by companies or open-source projects to manage many repositories and contributors in one place.

A team is a subgroup of members within an organization, used to manage permissions and notifications for a specific group of people, such as a particular department or project group.

Notifications alert you to relevant activity, such as being mentioned in a comment, a pull request being reviewed, or an issue being assigned to you, keeping you updated without constant manual checking.

A few final practical concepts you’ll run into constantly while actually using GitHub day to day.

Markdown is a simple, lightweight formatting language used throughout GitHub — in READMEs, issues, and comments — to add things like headings, bold text, and links using plain text symbols instead of a visual editor.

A personal access token is a secure, password-like credential used to authenticate with GitHub from the command line or other tools, often used instead of your actual account password for better security.

An SSH key is a pair of cryptographic keys that let you securely connect to GitHub without typing a password every time, commonly set up once on a development machine.

An HTTPS clone URL typically asks for a username and token when connecting, while an SSH clone URL uses your configured SSH key automatically — both achieve the same result of downloading a repository, just through different authentication methods.

GitHub Desktop is an official visual application that lets you perform common Git and GitHub actions (like committing and pushing) through buttons and menus, instead of typing commands in a terminal.

A Gist is a simple way to share a small snippet of code or text on GitHub, without needing to create a full repository for it, and can be public or kept private.

Not strictly — tools like GitHub Desktop let you perform most common actions visually, but learning the basic command-line commands gives you more control and is widely expected in professional development environments.

A branch is a separate line of work within the same repository, while a fork is an entirely separate copy of the repository under your own account — forks are typically used when you don’t have direct write access to the original project.

Yes — Git provides several ways to undo or modify previous commits, which is one of the core benefits of using version control in the first place, though the exact approach depends on whether the commit has already been pushed elsewhere.

While it’s built around code, GitHub is increasingly used for tracking any kind of versioned text content, including documentation, configuration files, and even non-technical collaborative writing projects.

If their changes don’t overlap, Git merges them automatically. If they modify the exact same lines differently, a merge conflict occurs, and a person needs to manually decide how to resolve it.