DEV Community

Flavius Dinu
Flavius Dinu

Posted on • Originally published at Medium on

Are you still searching for a Git and GitHub tutorial in 2025?

Search no more.

TL/DR?

Also, if you like the video, don’t forget to like, subscribe, and ring the bell for more videos like this. It helps more than you think!

What Are Git and GitHub?

Before touching a single command, clear up the most common beginner confusion: Git and GitHub are not the same thing.

  • Git is a version control system installed on your computer. It tracks every change you make to your project, maintains a full history, and lets you experiment with confidence. Accidentally deleted something? Git lets you revert. Introduced a bug? Git helps you identify and undo the exact change. It’s your local safety net and experiment playground.
  • GitHub is a cloud-based hosting service for Git repositories. If Git is the tool that manages history locally, GitHub is where you push that history to collaborate, back up, review code, manage issues, and coordinate work across a team.

Simple tip: Git lives on your machine; GitHub lives on the web. Throughout this tutorial, you’ll see how they work together in the professional workflow developers use every day.

Setup: Your First Steps

Enough theory. Let’s get everything installed and ready.

Create a GitHub Account

Your GitHub profile is your identity in the developer world. Go to GitHub’s signup page, enter your email, choose a username (pick something professional if you intend to show it to employers), set a password, verify your email, and skip optional “personalization” steps for now. You’ll land on your dashboard, your new home base.

Install Git

Git isn’t usually preinstalled, so you need to add it to your system:

  • Windows: Download the installer from the official Git site. Run it and accept the defaults. If prompted to choose a default editor, pick something like VS Code if you have it. Git Bash will be installed — it’s a great shell for running Git.
  • Mac: Open Terminal and type git. If it’s not installed, macOS will prompt to install Xcode Command Line Tools. Say yes. Alternatively, if you use Homebrew:
  • brew install git
  • Linux: Use your distribution’s package manager, e.g.,
  • sudo apt install git

After installation, verify it with:

git --version
Enter fullscreen mode Exit fullscreen mode

You should see a version number, congrats, Git is installed.

Configure Git

Tell Git who you are so commits are properly attributed:

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
Enter fullscreen mode Exit fullscreen mode

The --global flag makes this the default for all repositories on your machine.

Your First Repository

Now that tools are ready, let’s create a project space.

On GitHub

  1. Log into GitHub.
  2. Click the + in the upper-right and choose New repository.
  3. Fill in:
  • Repository name: e.g., hello-world
  • Description: A short sentence explaining the project.
  • Visibility: Choose Public for now.
  • Initialize with README: Check this, every project should have a README.

Skip .gitignore and license for today; you can add them later. Click Create repository.

You now have your first repository, a hosted project with an initial README.

Core Workflow: Clone → Add → Commit → Push

This is the daily loop of Git.

Clone the Repo Locally

On your repo page, click the green Code button, copy the HTTPS URL, then in terminal:

git clone https://github.com/your-username/hello-world.git
cd hello-world
Enter fullscreen mode Exit fullscreen mode

Now you have a full local copy, including history.

Make a Change

Edit README.md in your editor, and add something like:

This is my first local change.

Save the file.

Stage the Change

Staging tells Git what you intend to include in the next snapshot:

git add README.md
Enter fullscreen mode Exit fullscreen mode

Or stage everything:

git add .
Enter fullscreen mode Exit fullscreen mode

Commit the Change

A commit records the staged changes with a message:

git commit -m "Update README file with a new line"
Enter fullscreen mode Exit fullscreen mode

Push to GitHub

Send your local commit to the remote repository:

git push origin main
Enter fullscreen mode Exit fullscreen mode
  • origin is the default remote.
  • main is the primary branch.

After pushing, refresh your GitHub repo page and the change should appear. You’ve completed the full cycle: clone → edit → stage → commit → push. This is the foundation.

Understanding Branches: Parallel Universes

Branching is what makes Git transformative.

A branch is a separate line of development, a “parallel universe” of your project if you will. The main branch holds stable, production-ready code. To build a new feature safely, you branch off and experiment in isolation.

Let’s take a look on how to create a new branch:

git checkout -b new-feature
Enter fullscreen mode Exit fullscreen mode

You’ve created and switched to new-feature. Create a file:

touch new-feature-file.txt
git add .
git commit -m "Add file for the new feature"
Enter fullscreen mode Exit fullscreen mode

Switch back:

git checkout main
Enter fullscreen mode Exit fullscreen mode

The new file disappears, it lives only on new-feature. Switch back again:

git checkout new-feature
Enter fullscreen mode Exit fullscreen mode

The file returns. That isolation is what makes branching safe and powerful.

Pull Requests

Once your feature is ready, you want to merge it into main but in team environments, you do this through a Pull Request (PR).

Steps

Push your feature branch:

  • git push origin new-feature

On GitHub, you’ll see a prompt to Compare & pull request. Click it.

On the PR page:

  • Confirm you’re merging new-feature into main.
  • Give it a clear title (e.g., “Add New Feature”).
  • Write a descriptive body: what the change does, why it was made, and how to test it.

Next, create the PR and invite teammates to review. They can comment on specific lines, suggest changes, and approve.

Once approved, click Merge pull request. Optionally delete the old feature branch to keep things clean.

You’ve just followed a professional collaboration workflow: develop in isolation, request review, then merge.

Team Collaboration in Action

On a team, the repository is the single source of truth. Everyone clones it, works on their own branches, and integrates via PRs. Key practices:

Collaborators

Repository owners invite others under Settings → Collaborators , granting push access.

Branching Strategy (Feature Branch Workflow)

  • Never commit directly to main.
  • Create a new branch per task, e.g., feature/user-login or bugfix/fix-typo.
  • Work on that branch; commit as needed.
  • Open a PR to bring changes into main.
  • Require at least one reviewer’s approval.
  • Merge and delete the feature branch.

Stay Up to Date

Before starting new work:

git checkout main
git pull origin main
Enter fullscreen mode Exit fullscreen mode

git pull fetches and integrates others’ changes so your base is current.

Going Deeper: Advanced Concepts

Now that you’ve mastered the essentials, here are a few things that separate beginners from effective collaborators.

Structured Branching (e.g., Git Flow)

Large teams sometimes use models like Git Flow , which introduces branches like:

  • develop for integration of completed features,
  • release branches for stabilization,
  • main for production releases.

You don’t need this immediately, but it’s useful to know such conventions exist.

Merge Conflicts

Conflicts arise when two branches edit the same lines of the same file. Git will pause the merge and mark the conflict in the file with:

<<<<<<< HEAD
Your changes
=======
Their changes
>>>>>>> branch-name
Enter fullscreen mode Exit fullscreen mode

Resolve by editing the file to the desired state, then:

git add <file>
git commit
Enter fullscreen mode Exit fullscreen mode

Modern editors often have visual conflict resolution tools built-in to simplify this.

GitHub for Project Management

GitHub isn’t just for code, it’s a project hub.

  • Issues: Track tasks, bugs, ideas. Assign them, label them, and discuss context.
  • Project Boards: Visualize progress (like a Kanban). Drag PRs and Issues across columns like “To Do,” “In Progress,” and “Done.”

Mastering these lets you manage the code and the project around it.

Conclusion

You started by asking: What even is Git?

Now you’ve:

  • Installed and configured Git.
  • Created a GitHub repo.
  • Done the core workflow: clone, add, commit, push.
  • Used branching to isolate work safely.
  • Opened and merged a pull request.
  • Seen how teams coordinate through collaborators, reviews, and synchronization.
  • Touched on advanced ideas like structured branching, merge conflicts, and using GitHub as a project platform.

You’ve gone from confused beginner to someone with a real, professional workflow. The next step is practice: build your own projects, contribute to open-source, and keep using this loop until it becomes second nature.

If this guide helped, save it, share it, or subscribe to updates for more practical deep dives. You’re no longer just learning — you’re building. Now go make something awesome.

Top comments (0)