Tag: pull request

💡 Git basics don’t have to be scary — install it in minutes, configure your identity, and you’ll have a working local repository before your coffee gets cold.

Why Git Feels Overwhelming at First (And Why It Shouldn’t)

You’ve heard the word “Git” thrown around in every coding tutorial, bootcamp, and job description. And yet, somehow, the actual setup process feels weirdly underdocumented for beginners.

Here’s the thing. Git basics are genuinely simple once someone walks you through them without assuming you already know what a “working tree” is.

I remember the first time I tried to set up Git — I spent 45 minutes confused about whether I needed GitHub to use Git. Spoiler: you don’t. Git is local software. GitHub is just a place to put your Git projects online. Two different things.

Let’s fix that confusion right now.

Installing Git on Your Operating System

💡 Git installs in under two minutes on any OS — pick your platform and follow one command.

The installation process differs depending on your system, but none of them are complicated.

On Windows: Download the Git installer from git-scm.com. Run it, click through the defaults — honestly, the default settings are fine for most beginners. When the installer asks about your default editor, picking “Notepad” or “VS Code” (if you have it) is perfectly reasonable.

On macOS: Open Terminal and type git --version. If Git isn’t installed, macOS will prompt you to install it through Xcode Command Line Tools automatically. Or you can use Homebrew: brew install git. Either works.

On Linux (Ubuntu/Debian): Run sudo apt-get install git. Done. Seriously, that’s it.

After installation, open your terminal and run git --version. If you see a version number like git version 2.43.0, you’re good to go.

flowchart TD
    A[Start: Need Git?] --> B{What OS?}
    B --> C[Windows]
    B --> D[macOS]
    B --> E[Linux]
    C --> F[Download from git-scm.com\nRun installer]
    D --> G[brew install git\nor Xcode CLI tools]
    E --> H[sudo apt-get install git]
    F --> I[git --version ✓]
    G --> I
    H --> I
    I --> J[Git installed!]

Setting Up Your Git Username and Email

💡 Your Git identity is stamped on every commit you make — set it once and forget it.

Before you touch a single file, you need to tell Git who you are. This is non-negotiable. Every commit you make gets tagged with your name and email, so when you’re working with a team, everyone knows who changed what.

Run these two commands:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

The --global flag means this applies to every Git project on your machine. You can always override it per-project later by running the same commands without --global inside a specific folder.

💡 Use the same email address you’ll use for GitHub — it’s how contributions get linked to your account.

Want to double-check everything saved correctly? Run git config --list. You’ll see all your configuration settings printed out.

A friend of mine skipped this step when first learning Git and ended up with dozens of commits attributed to “undefined” in a shared repo. His team lead was not thrilled. Don’t be that person.

Initializing a Repository and Understanding the Basic Git Workflow

💡 A Git repository is just a folder that Git is watching — git init is the magic on/off switch.

Navigate to your project folder in the terminal. Then run:

git init

That’s it. Git just created a hidden .git folder inside your project directory. Everything Git needs to track your changes lives in there. Don’t delete it.

Now, the basic Git workflow follows a three-stage rhythm that’s worth burning into your brain:

• Working Directory — where you edit files normally
• Staging Area — where you prepare changes before saving them
• Repository — where Git permanently stores your snapshots (commits)

Think of it like packing a suitcase. You pull clothes from your closet (working directory), decide what to pack (staging area), then zip the bag shut (commit). You can keep adding and removing from the pile before you zip — that flexibility is the whole point.

flowchart LR
    A[Working Directory\nEdit files] -->|git add| B[Staging Area\nPrepare changes]
    B -->|git commit| C[Repository\nSaved snapshot]
    C -->|git checkout| A

Here’s a quick reference for the first commands you’ll use after git init:

Honestly, these four commands cover 80% of what you’ll do with Git in your first month. The rest builds on top of this foundation.

💡 Run git status obsessively at first — it tells you exactly where you stand and what Git is thinking.

One thing that tripped me up early: git add . stages everything in your current folder. That’s usually fine for personal projects, but get into the habit of checking git status first so you don’t accidentally commit a file with your API keys in it. (Yes, that happens. Constantly.)

The moment that setup clicks — when you run your first commit and see the confirmation message — something changes. It stops feeling like a chore and starts feeling like a superpower. You now have an undo button for your entire project.

That’s a big deal.

Related Articles

• Essential Git Commands Every Developer Should Know
• Collaborating on GitHub: Forking, Cloning, and Pull Requests
• Git Workflow for Real-World Projects

Back to Complete Guide: GitHub Tutorial for Beginners: Complete Git and GitHub Guide

💡 Mastering a dozen Git commands puts you ahead of most junior developers — here’s exactly which ones matter and why.

The Commands That Actually Matter (No Fluff)

Every Git tutorial online dumps 40 commands on you at once. Then you close the tab, open VS Code, and have absolutely no idea what to type.

Here’s a different approach. Let’s focus on the Git commands you’ll actually use in your first few months on a real team project — the ones that will save you from disasters and make your teammates trust your commits.

I went through my own command history from the first project I collaborated on and counted which commands I ran more than 10 times. The list was shorter than I expected.

Tracking Changes: git add, git commit, and git status

💡 These three commands form the core loop of daily Git work — everything else orbits around them.

Let’s be honest — git status is the most underappreciated command in existence. Run it constantly. It shows you what’s changed, what’s staged, and what Git doesn’t know about yet. When something weird happens, git status is your first diagnostic tool, always.

git add moves changes from your working directory to the staging area. You have options here:

• git add . — stages everything in the current directory
• git add filename.txt — stages one specific file
• git add -p — stages changes interactively, chunk by chunk (this one’s a game-changer, trust me)

Then git commit -m "your message here" saves the staged snapshot permanently. The message matters more than most beginners realize. “Fixed stuff” is useless. “Fix login redirect when session token expires” is gold.

💡 Write commit messages as if your future self needs to debug the project at 2 AM — because they might.

A teammate I worked with early on wrote every commit message as “update.” Every. Single. One. When we needed to roll back a specific change three weeks later, we had to read every single diff manually. Don’t do that to people.

Viewing History with git log

💡 git log is your project’s timeline — learn to read it and you’ll never lose track of what changed or when.

Plain git log shows you the full commit history with author, date, and message. It’s a lot of text. Here are the versions worth knowing:

The --oneline --graph combination is genuinely one of those things where once you see it, you’ll use it all the time. It draws a little ASCII tree showing how branches split off and merged back together.

Has anyone else noticed how much clearer project history becomes once you start reading it regularly? It’s almost like having a changelog built in automatically.

Branching: git branch and git checkout

💡 Branches let you experiment without breaking anything — they’re the feature that makes Git indispensable for teams.

This is where Git commands get genuinely powerful. A branch is just a separate line of development. Think of it as a parallel universe for your code.

The main branch (often called main or master) is your stable, working code. When you want to add a new feature, you create a branch, build it there, and only merge it back when it’s ready. If something goes wrong, your main branch is untouched.

gitGraph
   commit id: "Initial commit"
   commit id: "Add homepage"
   branch feature/login
   checkout feature/login
   commit id: "Add login form"
   commit id: "Connect to API"
   checkout main
   commit id: "Fix typo"
   merge feature/login id: "Merge login feature"
   commit id: "Release v1.0"

Here’s the core branching workflow:

1. git branch — lists all branches (the one with * is where you are)
2. git branch feature/my-feature — creates a new branch
3. git checkout feature/my-feature — switches to that branch
4. Or combine both: git checkout -b feature/my-feature

💡 Modern Git also supports git switch as a cleaner alternative to git checkout for branch switching — both work fine.

Naming your branches clearly matters for team sanity. feature/user-auth, fix/payment-bug, hotfix/null-pointer — patterns like these tell everyone what’s in a branch before they even look at the code.

When you’re done with a feature branch and it’s merged, clean up with git branch -d feature/my-feature. Stale branches pile up fast on active projects. I’ve seen repos with 200+ abandoned branches — it’s a mess.

Am I the only one who still mixes up git branch and git checkout occasionally after years of using them? Probably not. The muscle memory takes a few weeks to build, but once it does, branching becomes second nature.

The real payoff comes when you’re on a team and two people can work on completely different features simultaneously without ever stepping on each other’s code. That coordination — done right — is what separates chaotic projects from smooth ones.

Related Articles

• Getting Started with Git: Installation and Setup
• Collaborating on GitHub: Forking, Cloning, and Pull Requests
• Git Workflow for Real-World Projects

Back to Complete Guide: GitHub Tutorial for Beginners: Complete Git and GitHub Guide

💡 A pull request isn’t just a code submission — it’s the entire conversation around a contribution, and understanding it unlocks real open-source collaboration.

The Fork-Clone-Push-PR Cycle (And Why It Confuses Everyone)

Contributing to open source sounds intimidating until you’ve done it once. Then it just becomes a workflow — a repeatable pattern you run almost on autopilot.

The confusion usually comes from mixing up three things that sound similar: forking, cloning, and branching. They happen in a specific order for a reason. Get that order wrong and you’ll end up pushing to the wrong repository, which is exactly as awkward as it sounds.

I went through this the first time I tried contributing to a small open-source project — ended up cloning the original repository instead of my fork, made changes, then couldn’t push because I didn’t have write access. Spent an embarrassing amount of time figuring out what I’d done wrong.

Here’s the workflow, done correctly.

Step 1: Forking a Repository

💡 Forking creates your own copy of someone else’s project on GitHub — it’s the starting point for every external contribution.

When you find a project you want to contribute to, you can’t just push changes directly to it. You don’t have write access. Instead, you fork it — GitHub creates an identical copy of the repository under your account.

Click the “Fork” button in the top-right corner of any GitHub repository page. That’s it. Within seconds, you have your own version at github.com/your-username/project-name.

Your fork is independent. You own it completely. Changes you make there won’t affect the original project — called the “upstream” repository — unless you explicitly request them to via a pull request.

💡 Keep your fork up-to-date with the original project by adding the upstream remote: git remote add upstream [original-url], then periodically running git pull upstream main.

Step 2: Cloning to Your Local Machine

💡 Clone your fork — not the original — to work on it locally. This single distinction prevents a lot of beginner headaches.

Once your fork exists on GitHub, you need a local copy to actually edit files. That’s cloning.

git clone https://github.com/your-username/project-name.git

This downloads the entire repository — all files, all history — to a new folder on your machine. You’re now connected to your fork as the “origin” remote.

Before making any changes, create a feature branch. Working directly on main is technically possible but considered poor practice:

git checkout -b fix/typo-in-readme

Descriptive branch names matter here. When your pull request gets reviewed, that branch name is one of the first things maintainers see.

flowchart TD
    A[Find project on GitHub] --> B[Fork repository\nto your account]
    B --> C[Clone YOUR fork\ngit clone fork-url]
    C --> D[Create feature branch\ngit checkout -b feature/name]
    D --> E[Make changes\nEdit files locally]
    E --> F[Stage and commit\ngit add + git commit]
    F --> G[Push to your fork\ngit push origin branch-name]
    G --> H[Open Pull Request\non GitHub]
    H --> I{Review}
    I -->|Changes requested| E
    I -->|Approved| J[Merged! 🎉]

Step 3: Making Changes and Pushing to Your Fork

Make your changes. Run your tests. Check everything works. Then:

git add .
git commit -m "Fix typo in README installation section"
git push origin fix/typo-in-readme

The git push origin branch-name part is important — you’re pushing to your fork (origin), not the original project.

Here’s what a realistic example looks like. A developer I know — mid-20s, building their first open-source contributions portfolio — spotted a bug in a popular CSS framework’s documentation. The code examples in one section were outdated. They forked the repo, cloned it locally, created a branch called fix/update-flexbox-examples, updated three files, committed with a clear message, pushed to their fork, and opened a PR. The maintainer merged it within 48 hours. That contribution now sits on their GitHub profile permanently.

Small contributions like that are often the best starting point. Maintainers love documentation fixes and bug reports with reproducible examples.

Step 4: Submitting a Pull Request

💡 A great pull request description does half the reviewer’s job for them — don’t skip it.

After pushing your branch, GitHub will show a banner at the top of your repository suggesting you open a pull request. Click “Compare & pull request.”

You’ll see a form asking for a title and description. Fill both out properly. The title should be a clear one-liner: what changed and why. The description should explain:

• What problem this solves
• What you changed and why you chose that approach
• How to test it (if applicable)
• Any related issues (link them with “Fixes #123”)

After submission, maintainers will review your code. They might approve it, request changes, or ask questions. Respond promptly and professionally — this is a conversation, not a transaction.

Plot twist: getting a PR rejected or heavily reviewed early on is actually a good thing. The feedback teaches you the project’s standards faster than any documentation would. I’ve learned more from a single detailed code review than from hours of reading tutorials.

💡 If a maintainer requests changes, push new commits to the same branch — the pull request updates automatically without you needing to close and reopen it.

sequenceDiagram
    participant You
    participant YourFork
    participant OriginalRepo
    participant Maintainer

    You->>YourFork: git push origin feature/fix
    You->>OriginalRepo: Open Pull Request
    Maintainer->>OriginalRepo: Review code
    Maintainer-->>You: Request changes
    You->>YourFork: Push updated commits
    Maintainer->>OriginalRepo: Approve + Merge
    OriginalRepo-->>You: Contribution merged!

The whole fork-clone-push-PR cycle sounds like a lot of steps. The first time, it genuinely takes some focus. By the fifth time, you’ll run through it in under ten minutes without thinking.

Open source is built entirely on this workflow. Every library you’ve used, every framework you’ve depended on — the contributions that shaped them came through pull requests exactly like the one you’re about to open.

Related Articles

• Getting Started with Git: Installation and Setup
• Essential Git Commands Every Developer Should Know
• Git Workflow for Real-World Projects

Back to Complete Guide: GitHub Tutorial for Beginners: Complete Git and GitHub Guide

Here is the blog post:

—

💡 Real-world version control isn’t about memorizing commands — it’s about having a workflow your whole team can trust without stepping on each other’s toes.

Why Most Junior Devs Get Version Control Wrong (And Pay for It Later)

Version control is one of those things that feels simple until you’re three weeks into a team project and someone’s hotfix just obliterated two days of your work. I’ve seen it happen. Heck, I’ve caused it to happen, early on.

Here’s the uncomfortable truth: knowing git commit and git push isn’t enough. That’s like saying you know how to drive because you’ve operated a gas pedal. The real skill is understanding why branches exist, when to merge vs. rebase, and how to write a commit message that doesn’t make your teammates want to cry.

So let’s fix that — properly.

The Branch Model That Actually Works on Real Teams

💡 Three-branch discipline (main, develop, feature) prevents 80% of team-level Git disasters before they happen.

The branching model most professional teams use isn’t complicated, but it has to be consistent to work. Here’s how it breaks down:

• main — production-ready code only. Nobody commits here directly. Ever.
• develop — the integration branch. All finished features land here before going to main.
• feature branches — one branch per task, named something descriptive like feature/user-auth or fix/login-redirect-bug.

A friend of mine — junior dev, maybe six months into his first real job — skipped this entirely and pushed directly to main for two weeks before his team lead noticed. The resulting cleanup took a full afternoon and killed his credibility on the project. Not because he was bad at coding. Because he didn’t respect the system.

The math on this is surprisingly concrete. If your team has 4 developers each averaging 3 feature branches per sprint:

That middle layer — the develop branch — is what most beginners skip. And it’s the one that saves you.

flowchart TD
    A[feature/user-auth] -->|Pull Request| B[develop]
    C[feature/dashboard-ui] -->|Pull Request| B
    D[fix/login-bug] -->|Pull Request| B
    B -->|Release ready| E[main]
    E -->|Tag & Deploy| F[Production]

Merge vs. Rebase — This Is Where It Gets Real

💡 Use merge to preserve history on shared branches; use rebase to keep your own feature branch clean before a PR.

Okay, this is the part most tutorials gloss over. Let’s actually dig in.

git merge creates a merge commit — a new node in the graph that says “these two histories joined here.” It’s honest. It preserves exactly what happened and when. Use it when integrating develop into main, or when you want teammates to see the full picture.

git rebase rewrites your branch’s commits as if they started from the tip of another branch. Cleaner history. But — and this is important — never rebase a branch that other people are working on. I got this wrong the first time I used it. Rewrote commits on a shared feature branch, pushed it, and my colleague’s local copy was suddenly incompatible. We lost about 45 minutes untangling it.

The rule I follow now: rebase your own feature branch on top of develop before opening a pull request. Merge everything else.

Handling Merge Conflicts Without Panicking

Conflicts happen. They’re not a sign something went wrong — they’re a sign two people cared enough to both change something. Here’s a quick process that works:

1. Run git status to see exactly which files conflict.
2. Open each conflicted file — look for the <<<<<<< markers.
3. Decide which version is correct (or combine both).
4. Remove the conflict markers, then git add the file.
5. Complete the merge with git commit.

Has anyone else noticed how much easier this gets once you stop dreading it? The first conflict resolution feels like defusing a bomb. The tenth feels like editing a document.

Commit Messages and Code Reviews — The Underrated Half of Version Control

💡 A good commit message is a gift to your future self — write it like you’re explaining the “why,” not just the “what.”

Bad commit message: fix stuff

Good commit message: fix: redirect loop on login when session token expires (#204)

The difference matters more than most new devs realize. When something breaks in production at 2am six months from now, that commit message is what helps the on-call engineer understand what changed and why — without waking you up.

A format many teams adopt is Conventional Commits: prefix with feat:, fix:, chore:, docs:, etc. It plays nicely with automated changelogs and keeps your git log readable.

mindmap
  root((Version Control Habits))
    fa:fa-code-branch Branching
      main / develop / feature
      Descriptive names
    fa:fa-code-merge Integration
      Merge for shared branches
      Rebase before PR
    fa:fa-comment Commit Messages
      Conventional format
      Explain the why
    fa:fa-search Code Review
      Catch logic errors
      Knowledge sharing

Code reviews are the other half of this. They’re not just about catching bugs — though they do that too. They’re how institutional knowledge spreads through a team. When a senior dev comments “this will cause a race condition under load,” that’s a lesson you remember forever. Honestly, I learned more from six months of PR feedback than I did from a year of solo projects.

A few things worth checking in every review: does this introduce any security assumptions? Is the commit history clean enough to revert a single change if needed? Could a new teammate understand what this does without asking anyone?

Version control at its best isn’t just a backup system. It’s a communication tool — between teammates, and between you today and you six months from now.

Related Articles

• Getting Started with Git: Installation and Setup
• Essential Git Commands Every Developer Should Know
• Collaborating on GitHub: Forking, Cloning, and Pull Requests

Back to Complete Guide: GitHub Tutorial for Beginners: Complete Git and GitHub Guide

You wrote the code. It worked perfectly. Then you changed something — and now nothing compiles, you can’t remember what you changed, and the original version is just… gone.

That feeling is exactly why version control exists. And Git plus GitHub is how literally millions of developers avoid that nightmare every single day. Seriously — once you get this, you’ll wonder how you ever coded without it.

The good news? You don’t need to understand everything at once. This guide breaks it down into four focused chapters, so you can go from “what even is a commit?” to opening your first pull request on a real project. I went through this exact learning curve myself a few years back, and I’m going to share the parts I wish someone had explained clearly upfront.

Table of Contents

1. Getting Started with Git: Installation and Setup
2. Essential Git Commands Every Developer Should Know
3. Collaborating on GitHub: Forking, Cloning, and Pull Requests
4. Git Workflow for Real-World Projects

Getting Your Environment Ready

💡 Before you write a single command, you need Git installed and your identity configured — otherwise none of the collaboration features work properly.

Most beginners skip straight to the “cool stuff” and hit a wall within 20 minutes because their setup is broken. Don’t do that. Getting Git installed correctly and linking it to your GitHub account takes maybe 10 minutes, and it prevents hours of frustration later.

There’s also a configuration step that trips people up: telling Git who you are. Your name and email get attached to every commit you make. A developer I know skipped this on a work machine and ended up with two years of commits attributed to the wrong email — a minor nightmare when it came time to review contribution history.

Read the Full Guide: Getting Started with Git: Installation and Setup

The Commands You’ll Actually Use

💡 About 90% of your daily Git usage comes down to six or seven commands — master those first, everything else is situational.

When I first opened a list of Git commands, I counted somewhere north of 150 of them. That’s overwhelming. Here’s the thing though — you don’t need most of them, at least not yet. Day-to-day Git work is mostly git add, git commit, git push, git pull, and git status. That’s it.

The tricky part isn’t memorizing the commands — it’s understanding when to use them and what state your repository is in at any given moment. Branching especially confuses beginners at first. (Honestly, I got branches wrong multiple times before it clicked.) The guide below walks through each command with real examples, not abstract theory.

Read the Full Guide: Essential Git Commands Every Developer Should Know

Collaborating Without Breaking Things

💡 Pull requests aren’t just a GitHub feature — they’re the professional standard for proposing and reviewing code changes safely.

This is where Git goes from a personal backup tool to a full collaboration platform. Forking lets you copy someone else’s project into your own GitHub account so you can experiment freely. Cloning pulls that copy down to your local machine. And pull requests — often called PRs — are how you say “hey, I made something, want to include it?”

The workflow feels formal at first. But after doing it a few times, you realize it’s actually protecting everyone involved. The project maintainer reviews your changes before anything gets merged. You get feedback. Nothing breaks in production without at least one other set of eyes on it. Has anyone else noticed how much calmer code reviews feel when there’s a structured PR process? It genuinely changes the dynamic.

Read the Full Guide: Collaborating on GitHub: Forking, Cloning, and Pull Requests

Applying This to Real Projects

💡 Knowing the commands is one thing — building a consistent workflow for a team-based project is where Git actually saves you from chaos.

There’s a gap between “I understand Git commands” and “I can manage a real codebase without causing problems.” A friend of mine joined a startup earlier this year, already comfortable with basic Git, and still pushed directly to main on his first week. The senior devs were… not thrilled. The issue wasn’t his skill — it was workflow.

Real teams use conventions: feature branches, protected main branches, commit message standards, regular rebasing or merging from upstream. This guide covers the practical patterns that professional teams actually use, including how to structure your branches and keep your history readable.

Read the Full Guide: Git Workflow for Real-World Projects

Frequently Asked Questions

What is the difference between Git and GitHub?

Git is the version control software itself — it runs locally on your machine and tracks changes to your files. GitHub is a cloud platform that hosts Git repositories and adds collaboration features like pull requests, issues, and project boards. You can use Git without GitHub entirely, but GitHub makes sharing and working with others dramatically easier. Think of Git as the engine and GitHub as the garage where you park and show off the car.

How do I resolve a merge conflict?

A merge conflict happens when two branches change the same line of code differently, and Git doesn’t know which version to keep. Git marks the conflict directly in the file with <<<<<<< and >>>>>>> markers showing both versions. You manually edit the file to keep whichever version (or combination) is correct, remove the conflict markers, then run git add and git commit to complete the merge. It sounds scarier than it is — most conflicts resolve in under two minutes once you’ve done it a few times.

Can I undo a commit in Git?

Yes — and this is one of Git’s most underappreciated strengths. If the commit hasn’t been pushed yet, git reset --soft HEAD~1 undoes the commit but keeps your changes staged. If you’ve already pushed, the safer option is git revert, which creates a new commit that undoes the previous one without rewriting history. Avoid git reset --hard on shared branches unless you’re absolutely certain — it discards changes permanently.

Where to Go From Here

Git has a reputation for being intimidating, but most of that reputation comes from people jumping into advanced topics before the fundamentals are solid. Work through the four guides above in order. By the time you finish the workflow chapter, you’ll be operating at the level that most junior developers take months to reach.

The fastest way to actually retain this is to practice on a real project — even a small personal one. Push something to GitHub this week. Open a branch. Make a pull request to yourself. The muscle memory builds fast once you’re doing it for real, not just reading about it.