The Ultimate Beginner’s Guide to Git & GitHub: From First Commit to Pull Requests

In today’s development world, version control isn’t optional—it’s essential. Git and GitHub have become the industry standard, powering everything from small personal projects to massive open-source collaborations. Yet for many beginners, these tools can feel like learning a foreign language.

Why should you care? Because mastering Git and GitHub will:

• Make your coding projects more organized and recoverable
• Enable seamless collaboration with other developers
• Showcase your work to potential employers
• Give you the confidence to contribute to open-source projects

This guide breaks down Git and GitHub concepts into plain, everyday language—the way one developer would explain it to another over coffee. Whether you’re coding solo or as part of a team, you’ll finish this guide with a clear understanding of how these powerful tools fit into your workflow.

1. Getting Started: When Does a Folder Become a Git Repo?

Your regular folder transforms into a Git repository the moment you run this simple command:

git init

That’s it! This creates a hidden .git folder inside your project that starts tracking all your changes. Think of it like installing a security camera in your code—it’s now watching every addition, deletion, and modification you make.

What happens behind the scenes:

• Git creates a database to store all versions of your files
• Your folder now has a complete history-tracking system
• You can start recording snapshots (commits) of your work

Pro tip: Run ls -la (Mac/Linux) or dir /a (Windows) to see the hidden .git folder that was created.

2. Connecting to GitHub: How Remote Origin Works

After creating your local Git repo, you’ll want to connect it to GitHub. This is where remote origin comes in.

To link your local repo to GitHub:

git remote add origin https://github.com/your-username/your-repo.git

What this actually means:

• remote tells Git you’re working with a remote repository
• add is the action you’re taking
• origin is just a nickname for your GitHub repository (you could call it “github” or “cloud” if you wanted)
• The URL is the actual address where your code will live online

Think of origin like setting your home address in Google Maps—it’s giving Git directions to where your code should go when you push it.

Checking your remote connection:

git remote -v

This will show you something like:

origin  https://github.com/your-username/your-repo.git (fetch)
origin  https://github.com/your-username/your-repo.git (push)

Need to disconnect or change repositories?

git remote remove origin

This removes the connection completely, allowing you to set up a new one if needed.

3. Collaboration Basics: Pull Requests Explained

Do you always need a Pull Request?

No—especially not if you’re working alone. When flying solo, you can push directly to your main branch without ceremony.

However, Pull Requests become essential when:

• You’re working with others
• You want feedback before merging changes
• You’re contributing to an open-source project
• Your team has quality control standards

What exactly is a Pull Request?

A Pull Request (PR) is essentially saying: “Hey team, I’ve made some changes in this branch. Can someone review them before we add them to our main code?”

Think of it as asking someone to proofread your email before sending it to an important client.

The basic workflow:

1. Create a branch for your feature/fix: git checkout -b new-feature
2. Make your changes and commit them
3. Push your branch to GitHub: git push origin new-feature
4. On GitHub, click “Compare & pull request”
5. Add a description explaining your changes
6. Submit the PR for review

When to skip Pull Requests:

• Personal projects where you’re the only contributor
• Quick fixes where review would add unnecessary delay
• Early-stage projects with no production users

When Pull Requests are non-negotiable:

• Team environments with code quality standards
• Open-source contributions
• Any code that will run in production
• Projects with testing requirements

4. Who’s in Charge? Pull Request Approval Process

Once you’ve submitted a Pull Request, who decides if it gets merged?

Pull Requests can be approved by:

• Repository owners
• Project maintainers
• Team members with write/admin permissions
• Anyone designated as a reviewer

The approval process typically follows these steps:

1. Review: Designated reviewers examine your code changes
2. Feedback: Reviewers may leave comments, suggest changes, or approve
3. Discussion: You can respond to comments and make additional commits
4. Resolution: After addressing feedback, reviewers approve the PR
5. Merge: Once approved, the PR can be merged into the target branch

Types of responses you might get:

• Approved: Green light to merge
• Changes requested: Fixes needed before approval
• Commented: Feedback without explicit approval/rejection
• Dismissed: Previous review no longer applies (after new commits)

Think of Pull Request approval like peer review in academic publishing—your work needs to meet the team’s standards before being accepted.

Good Pull Request etiquette:

• Keep changes focused and reasonably sized
• Write clear descriptions of what you changed and why
• Respond promptly to feedback
• Thank reviewers for their time

5. Bringing It Together: What Happens During a Merge

When your Pull Request is approved and merged, here’s what actually happens:

The merge process:

1. Git compares the differences between your branch and the target branch
2. It creates a new “merge commit” that combines both histories
3. Your changes become part of the target branch
4. Your original branch remains unchanged (but can be deleted if no longer needed)

Types of merges:

1. Fast-forward merge: When there are no new changes in the target branch, Git simply moves the pointer forward.
2. Three-way merge: When both branches have diverged, Git creates a new commit combining both histories.
3. Squash merge: Combines all your branch’s commits into a single commit before merging.
4. Rebase: Replays your changes on top of the target branch, creating a linear history.

Important to understand:

• Merging adds all your branch’s changes to the target branch
• This includes both the good (features) and the bad (bugs)
• That’s why proper testing and review before merging is crucial

6. Team Visibility: Do Others See My Branches?

Yes, your branches are visible to team members—but only after you push them to GitHub.

Here’s how branch visibility works:

1. Local branches: When you first create a branch on your computer (git checkout -b feature), it exists only on your machine.
2. Remote branches: After you push your branch (git push origin feature), it becomes visible to everyone with access to the repository.

Once your branch is on GitHub, team members can:

• See it in the branches list
• View all commits in that branch
• Check out your branch to their local machine
• Make their own commits to your branch (if they have permission)
• Create Pull Requests from your branch

Branch privacy considerations:

• Branches in private repositories are only visible to collaborators
• Branches in public repositories are visible to everyone
• There’s no way to make a specific branch private within a repository

Think of branches like drafts in a shared Google Doc—once you share them, everyone with access can see your work in progress.

7. Contributing to Public Projects: Forking vs Cloning

When you want to work with someone else’s public repository, you have two options: forking and cloning.

Forking:

What it is: Creating your own copy of someone else’s repository under your GitHub account.

When to use it:

• Contributing to open-source projects
• Making significant changes to someone else’s code
• Creating your own version of an existing project

How it works:

1. Click “Fork” on the original repository
2. GitHub creates a copy under your account
3. You clone your fork to your local machine
4. Make changes and push to your fork
5. Create a Pull Request to the original repository

Cloning:

What it is: Downloading a repository directly to your local machine.

When to use it:

• When you just need to use or study the code
• When you have write access to the original repository
• For personal use without contributing back

How it works:

1. Copy the repository URL
2. Run git clone [URL] on your computer
3. Make changes locally
4. Push changes (only works if you have permission)

The key difference:

• Forking creates a separate copy you fully control
• Cloning just downloads the existing repository

Think of forking as photocopying a document (creating your own version), while cloning is just borrowing the book from the library.

8. Visual Git: Using GitHub Source Control in VS Code

Visual Studio Code makes Git much more approachable with its built-in Source Control panel.

To access it: Click on the Source Control icon in the sidebar (it looks like a branch with circles).

What you can do without touching the terminal:

• Initialize a repository
• Stage changes
• Write commit messages
• Push and pull changes
• Create and switch branches
• View file differences
• Resolve merge conflicts

Getting started with VS Code Source Control:

1. Open your project folder in VS Code
2. Click the Source Control icon
3. Click “Initialize Repository” if your folder isn’t a Git repo yet
4. Make changes to your files
5. Click the “+” icon next to modified files to stage them
6. Type a commit message in the text box
7. Click the checkmark to commit
8. Use the “…” menu for additional options like pushing to GitHub

Connecting to GitHub: While VS Code handles most Git operations visually, you might still need the terminal for your first remote connection:

git remote add origin https://github.com/your-username/your-repo.git

After that, you can push/pull using the GUI buttons.

9. Terminal vs GUI: Git Command Line vs VS Code Source Control

Both approaches have their strengths—here’s when to use each:

Command Line Advantages:

• Complete control: Access to all Git features and options
• Efficiency: Faster for experienced users
• Consistent: Works the same way across all environments
• Scriptable: Can be automated or included in build processes

VS Code Source Control Advantages:

• Visual feedback: See exactly what’s changed
• Easier learning curve: Good for beginners
• Integrated experience: Code and manage Git in one place
• Interactive conflict resolution: Visual merge conflict tool

Recommended approach: Use both! Start with VS Code’s visual tools while you’re learning, then gradually incorporate command line Git as you become more comfortable.

Common operations compared:

Action	Command Line	VS Code
Initialize repo	git init	Click “Initialize Repository”
Stage changes	git add .	Click “+” icon next to files
Commit	git commit -m "message"	Type message and click ✓
Switch branch	git checkout branch-name	Click branch name in status bar
Push changes	git push origin main	Click cloud icon with up arrow

10. GitHub Community: Understanding GitHub Badges

GitHub badges are small achievements displayed on your profile that recognize your contributions and activities. Think of them as merit badges for developers.

Popular badges include:

• Pull Shark: Awarded for having Pull Requests merged
• Arctic Code Vault Contributor: Your code was preserved in the GitHub Arctic Code Vault
• YOLO: You’ve done a force-push to main/master (not something to aim for!)
• Pair Extraordinaire: Co-authored commits with another developer
• Starstruck: When your repository gets many stars

Why badges matter:

• They showcase your GitHub activity and experience
• They help build your developer identity
• They can be conversation starters in interviews
• They encourage positive contribution habits

How to earn badges:

• Participate regularly in GitHub
• Contribute to open-source projects
• Create quality repositories that others star
• Collaborate with other developers

While badges aren’t professional certifications, they do signal your familiarity with GitHub and development workflows.

11. Step by Step: Complete Git Workflow Walkthrough

Here’s a complete workflow from project creation to GitHub publication, with explanations:

Starting a new project:

# Create a project folder
mkdir my-awesome-project
cd my-awesome-project

# Initialize as a Git repository
git init
# Creates the hidden .git folder that tracks everything

# Create a .gitignore file right away
touch .gitignore
# We'll add to this later

# Create your first file
echo "# My Awesome Project" > README.md

# Stage your file
git add README.md
# This prepares the file to be committed

# Commit your first change
git commit -m "Initial commit with README"
# This creates a permanent snapshot of your file

Connecting to GitHub:

# Create a repo on GitHub first, then:
git remote add origin https://github.com/your-username/my-awesome-project.git
# This links your local repo to GitHub

# Push your code to GitHub
git push -u origin main
# -u sets up tracking, so future pushes can be just 'git push'

Making changes with branches:

# Create a new branch
git checkout -b add-feature
# Creates and switches to a new branch

# Make your changes and save them

# Stage and commit
git add .
git commit -m "Add new feature"

# Push branch to GitHub
git push origin add-feature

Creating a Pull Request:

1. Go to your GitHub repository
2. Click “Compare & pull request” button
3. Add a title and description
4. Click “Create pull request”

After PR approval:

# Switch back to main branch
git checkout main

# Pull the latest changes (including your merged PR)
git pull origin main

# Delete your feature branch (optional)
git branch -d add-feature

The .gitignore file is one of the most important but often overlooked parts of Git setup. It tells Git which files and directories to ignore completely.

Why is this crucial?

1. Security: Prevents sensitive information from being published
2. Repository size: Keeps your repo lean by excluding large files
3. Cleanliness: Avoids cluttering your repo with temporary files

Common items to ignore:

# Dependencies
node_modules/
vendor/

# Environment variables and secrets
.env
.env.local
config.json

# Operating system files
.DS_Store
Thumbs.db

# Build outputs
dist/
build/
*.log

# IDE-specific files
.idea/
.vscode/
*.sublime-project

How to use .gitignore:

1. Create it at the root of your repository
2. Add patterns for files/folders to ignore, one per line
3. Use wildcards like *.log to match patterns
4. Use /folder to ignore only at the root level
5. Use folder/ to ignore folders with that name at any level

Important: .gitignore only works for files that haven’t been tracked yet. If you’ve already committed a file, you need to untrack it first:

git rm --cached sensitive_file.txt

Then add it to .gitignore to prevent future tracking.

Pro tip: Use templates! GitHub offers language-specific .gitignore templates for nearly every programming language and framework.

13. Troubleshooting: Common Git Problems Solved

Even experienced developers run into Git issues. Here are solutions to common problems:

“Help! I committed to the wrong branch!”

# Undo the last commit but keep the changes
git reset HEAD~1

# Switch to the correct branch
git checkout right-branch

# Re-stage and commit
git add .
git commit -m "Your commit message"

“I need to undo my last commit entirely”

# Completely remove the last commit and changes
git reset --hard HEAD~1

“I have a merge conflict!”

1. Open the conflicted files (they’ll be marked in VS Code)
2. Look for the conflict markers (<<<<<<<, =======, >>>>>>>)
3. Edit the file to keep what you want
4. Stage the resolved files: git add <filename>
5. Continue the merge: git merge --continue

“I accidentally committed sensitive information”

# Remove the file from Git history
git filter-branch --force --index-filter \
"git rm --cached --ignore-unmatch PATH-TO-FILE" \
--prune-empty --tag-name-filter cat -- --all

# Force push to remote
git push origin --force --all

Warning: This rewrites history! Only use when absolutely necessary.

“Git says ‘fatal: refusing to merge unrelated histories'”

# When pulling from a remote that has history unrelated to yours
git pull origin main --allow-unrelated-histories

“I’m in ‘detached HEAD state’ – what does that mean?”

# Create a branch where you are
git checkout -b new-branch-name

# Or go back to an existing branch
git checkout main

Remember: Git always keeps your committed changes for at least 30 days, even if they seem “lost.” Use git reflog to find them.

14. Git in Practice: Real-World Example

Let’s walk through a realistic scenario: adding a feature to a team project.

The scenario: You need to add a login page to your team’s website.

Step 1: Get the latest code

git checkout main
git pull origin main

Step 2: Create a feature branch

git checkout -b feature/login-page

Step 3: Make your changes

Create the login page files, write the code, test it works.

Step 4: Commit in logical chunks

# Add the HTML structure
git add login.html
git commit -m "Add login page HTML structure"

# Add the styling
git add styles/login.css
git commit -m "Add login page styles"

# Add the JavaScript functionality
git add scripts/login.js
git commit -m "Add login form validation and API integration"

Step 5: Stay up-to-date with main

# Get latest changes from main
git checkout main
git pull origin main

# Return to your branch and merge in main's changes
git checkout feature/login-page
git merge main

# Resolve any conflicts if they occur

Step 6: Push your branch and create a PR

git push origin feature/login-page

Go to GitHub and create a Pull Request with:

• Clear title: “Add user login page”
• Description explaining what you did and how to test it
• Any screenshots of the new feature

Step 7: Address feedback

As reviewers comment on your PR, make additional commits to address their points.

Step 8: PR approved and merged

After approval, your code is merged into main.

Step 9: Clean up

git checkout main
git pull origin main  # Get your merged changes
git branch -d feature/login-page  # Delete your local branch

This workflow ensures code quality, maintains a clean history, and keeps the team informed about changes.

15. Summary and Next Steps

Key Takeaways:

• Git is local, GitHub is remote: Git tracks changes on your computer; GitHub stores them in the cloud
• Branches are your friends: Use them to organize features and fixes
• Pull Requests enable collaboration: They’re conversation tools as much as code tools
• Clean commits tell a story: Make each commit focused and descriptive
• .gitignore prevents mistakes: Set it up early to avoid leaking secrets
• Both terminal and GUI have value: Learn both for maximum flexibility

Development Best Practices:

• Commit early and often
• Write clear, specific commit messages
• Create a new branch for each feature or fix
• Keep Pull Requests focused on a single change
• Review your own code before requesting reviews
• Always pull before starting new work
• Use .gitignore appropriately

Next Steps to Level Up Your Git Skills:

1. Learn Git Hooks: Automate tasks like linting before commits
2. Explore GitHub Actions: Set up CI/CD workflows
3. Master Interactive Rebase: Clean up your commit history
4. Contribute to Open Source: Apply your skills in the wild
5. Try Git Bisect: Find which commit introduced a bug

Git Resources:

• GitHub Skills – Interactive courses
• Pro Git Book – Free comprehensive guide
• Oh Shit, Git!?! – Solutions to common mistakes
• GitHub Docs – Official documentation

Your Git Cheat Sheet:

Task	Command
Create repo	git init
Clone repo	git clone URL
New branch	git checkout -b branch-name
Stage changes	git add .
Commit	git commit -m "message"
Push	git push origin branch-name
Pull	git pull origin branch-name
Merge branches	git merge branch-name
View history	git log
View changes	git diff

Remember: Git becomes intuitive with practice. The more you use it, the more natural it feels!

Connect and Share

Did you find this guide helpful? I’d love to hear from you!

• Share your own Git tips in the comments
• Let me know what topics you’d like covered next
• Connect with me on LinkedIn
• Follow CodingNaija for more developer guides

Happy coding, and may your commits always be clean and your merges conflict-free! 🚀