Introduction
Almost every software team in the world uses Git, and almost every open-source project lives on GitHub. Yet for a beginner, the two words blur together, the commands look cryptic, and the first time a teammate says "just open a pull request", it can feel like being asked to do something in a language you have not learned yet.
The core idea is simple. Git is a tool that remembers every version of your code. GitHub is a website where those versions live online, so a team can share them. Once you understand a handful of concepts — repositories, commits, branches, and pull requests — the rest is practice.
What Git Actually Is
Git is version control. It is a system that tracks every change you make to a set of files, so you can see what changed, when it changed, and who changed it — and go back to an earlier version whenever you need to.
Imagine saving a new copy of a document every time you finish a piece of work — report-v1.docx, report-v2-final.docx, report-v2-final-really-final.docx — and eventually opening the wrong copy. Git replaces that mess with a single folder that remembers its own history.
That folder is called a repository, or repo for short. Inside it, Git stores a complete timeline of your project, and each point on the timeline is a snapshot of all your files at that moment. You can move between snapshots, compare two of them, or undo a change without losing the work that came after it.
Git works on your own computer, even with no internet connection. You do not need an account, a server, or a team to use it — it is useful from the very first day, on a solo project, before any collaboration begins.
What GitHub Adds
If Git is the tool on your computer, GitHub is the place online where teams keep their repositories. It is a hosting service built around Git, and it adds the features a team needs to work together: a shared copy of the repo, a place to discuss changes, a way to review code before it is merged, and tools for tracking issues and planning work.
The distinction matters. Git and GitHub are not the same thing, and you can use Git without GitHub. Many teams do use GitHub, though, because it solves the obvious problem: if the code only lives on your laptop, nobody else can see it, change it, or help you fix it.
On GitHub, a repository has a page where anyone with access can see the files, the history, and the open discussions. When you push your local history to GitHub, your teammates can pull it down to their own machines. The shared copy becomes the source of truth, and each developer keeps their own local copy for day-to-day work.
GitHub also hosts millions of open-source projects, which makes it a good place to learn. Reading the history of a real project — its commits, branches, and pull requests — shows you how experienced developers actually work.
Your First Repository
The fastest way to learn Git is to make a small repository and use it for a real piece of work, even a tiny one — a notes file, a practice website, or a small script.
Create a folder for the project and, in the terminal inside it, run git init. That creates a hidden .git directory, where Git stores the entire history. From that moment, the folder is a repository.
Next, create a file — say, a simple index.html — and add it with git add. Adding a file does not save it permanently; it stages it, telling Git "include this file in the next snapshot". Then git commit -m "Add the first page" takes the snapshot, with a short message describing what you did.
That three-step rhythm — change files, stage them, commit them — is the heartbeat of Git. The habit to build early is committing often, in small steps, with messages that describe what changed and why.
Commits: The Unit of Change
A commit is the basic unit of work in Git: a snapshot of your project at one moment, plus a message, an author, and a timestamp. Everything else in Git — branches, merges, pull requests — is built on top of commits.
Good commits are small and well described. A commit that changes one thing is easy to review, easy to undo, and easy to understand six months later. A commit that changes twenty unrelated things is none of those.
Write commit messages in the imperative mood, as if giving an instruction: "Fix the login redirect", "Add validation to the signup form". This is the convention most teams follow, and it keeps the history readable. The first line should be short — under fifty characters if you can manage it — and if a change needs explanation, add a longer paragraph below it.
One practical rule helps more than any other: commit when something works. If you have been working for an hour without committing, that is usually a sign the change has grown too large and should be split. A clean history is what lets you find a bug, undo a mistake, and explain your work later.
Branches: Working Without Breaking Things
A branch is a separate line of work inside the same repository. When you create a branch, you get a copy of the project at its current state, and you can change it freely without affecting the main line of work. When the work is done, you merge the branch back in.
This is how teams avoid stepping on each other's toes. The main branch — usually called main — holds the stable, working version of the project. Nobody edits it directly. Instead, each developer creates a branch for their task, with a descriptive name like fix-login-redirect or add-search-page, and works there.
Creating a branch is cheap and instant, which is the point. In older version control systems, branching was slow and painful, so developers avoided it. In Git, it costs almost nothing, so the normal way to work is to branch for everything: a bug fix gets a branch, a feature gets a branch, even a small experiment gets a branch.
Try it on your own repository: create a branch, change a file, commit, and switch back to main. Your change will be gone from the working files — it lives on the branch, safe and separate. Switch back to the branch, and it returns.
Merging and Handling Conflicts
Merging is how a branch's work returns to the main line. When you merge, Git combines the changes from your branch with the changes on main since you branched off. Most of the time this happens automatically, because the two sides changed different parts of the code.
Sometimes they changed the same lines, and Git cannot decide which version is correct. That is a merge conflict, and it is the part of Git beginners fear most. In practice, it is ordinary and fixable.
A conflict looks like a file with markers showing both versions: the lines from your branch, and the lines from main, with a clear dividing line between them. Your job is to read both versions, decide what the file should actually say — sometimes one side, sometimes the other, sometimes a combination — remove the markers, and commit the result.
Two habits make conflicts rare and painless. First, keep branches short-lived: merge back within a day or two, before main has moved far away from yours. Second, pull the latest changes from main into your branch regularly. Long-lived branches are where painful conflicts are born.
The GitHub Workflow: Pull Requests
A pull request is GitHub's way of proposing a change. You push your branch to GitHub, open a pull request, and ask your teammates to review it before it is merged into main. The pull request shows exactly what changed, line by line, and gives reviewers a place to comment, ask questions, and request changes.
The typical team workflow looks like this. First, you pull the latest main and create a branch for your task. You make your changes in small commits and push the branch to GitHub. Then you open a pull request with a short description of what the change does and why. A teammate reviews the code, leaves comments, and either approves it or asks for changes. You address the feedback, push more commits to the same branch, and the pull request updates automatically. When it is approved, the branch is merged, and the branch is deleted.
This workflow has a benefit that is easy to miss: it makes code review a normal, everyday event rather than a rare, scary one. Small pull requests, reviewed quickly, catch bugs early and spread knowledge around the team, so over time everyone understands the codebase better.
For a beginner, the first pull request is a milestone. It means you have gone through the full cycle: branch, commit, push, propose, review, merge. After that, the workflow stops feeling like a set of rules and starts feeling like how work gets done.
Common Mistakes to Avoid
The most common beginner mistake is committing too rarely. A day's work in a single commit is hard to review, hard to undo, and hard to explain. Commit in small steps, and write messages that describe the change.
The second mistake is committing files that should never be in a repository: passwords, API keys, and large generated files. A .gitignore file tells Git which files to skip, and every project should have one from the start. If a secret does get committed, removing the file in a later commit is not enough — the secret is still in the history — so treat secrets as something that must never enter Git at all.
The third mistake is working directly on main. It feels faster, and for a solo project it often is, but it teaches the wrong habit. Branches exist to protect the stable version of your code. Use them even when you are working alone, so the habit is already there when you join a team.
The fourth mistake is ignoring the pull request description. A reviewer who has to guess what a change is for will review it slowly and badly. A few sentences — what changed, why, and how to test it — make review faster and better for everyone.
Finally, do not be afraid of making a mess. Git is designed to be forgiving: almost every mistake can be undone, and the history is there precisely so that experiments are safe.
Conclusion
Git and GitHub look complicated from the outside because they have a lot of vocabulary: repositories, commits, branches, merges, pull requests. Underneath, the idea is simple. Git remembers every version of your code, branches let you work without breaking the stable version, and pull requests let a team review changes before they become permanent.
Start small. Make a repository, commit often, branch for every task, and open a pull request even when you are working alone. Within a few weeks, the workflow will feel natural — and you will have the skill almost every software job expects.
Frequently Asked Questions
What is the difference between Git and GitHub? Git is the version control tool that runs on your computer and tracks changes to your files. GitHub is a website that hosts Git repositories online, so a team can share code, review changes, and collaborate. You can use Git without GitHub, but most teams use both together.
Do I need to know the command line to use Git? It helps, and the commands are worth learning, because tutorials and teammates will refer to them. But you do not have to start there: GitHub Desktop, VS Code, and other tools provide buttons for the common operations. Learn the concepts first, then the commands, in whatever order feels comfortable.
What should I write in a commit message? A short first line in the imperative mood, describing what the change does: "Fix the login redirect" or "Add validation to the signup form". If the change needs more explanation, add a longer paragraph after a blank line. Good messages make the project history readable months later.
What is a pull request, in simple terms? A pull request is a proposal to merge one branch into another, usually into main. It shows exactly what changed, and it gives teammates a place to review the code and discuss it before the change becomes permanent.
What should I do if I get a merge conflict? Do not panic. Open the conflicted file, read both versions marked in it, decide what the file should actually say, remove the conflict markers, and commit the result. Conflicts are a normal part of teamwork, and keeping branches short-lived makes them rare and small.
Comments
Post a Comment