How to Use Git and GitHub: A Step-by-Step Tutorial

bash\n git branch feature-name\n bash\n git checkout -b feature-name\n bash\n git checkout feature-name\n bash\n git checkout main\n bash\n git merge feature-name\n bash\ngit add conflicted-file.js\ngit commit\nbash\n git push -u origin feature-name\n

ini\n[alias]\n st = status\n co = checkout\n ci = commit\n br = branch\n lg = log –oneline –graph –all\n last = log -1 HEAD\nbash\ngit st # Shows status\ngit co dev # Checks out ‘dev’ branch\ngit ci -m \”Update readme\” # Creates a commit\n

There’s a lot of noise around Git and GitHub, and too often they get tossed around like they’re the same thing. They’re not. Git is a version control system—a tool that lives on your local machine. It tracks changes to files, helps you roll back mistakes, branch out experiments, and keeps a history of everything. You don’t need internet, accounts, or a UI. It’s the engine.

GitHub, on the other hand, is the garage. It’s a hosted platform where your Git repositories can live online. GitHub makes it easier to share, collaborate, and manage code with teams. It adds features like pull requests, issue tracking, and a web interface—but under the hood, it still runs on Git.

Now, why should you care—especially if you’re a solo dev or UX designer? Because version control isn’t just for massive teams. It saves you when you break a feature, helps you try bold ideas without wrecking your main project, and creates a clean log of what’s been done. For designers, swapping out design files is clunky. Git (and tools that support designers) let you treat creative projects like living documents.

In the real world, Git lets developers move fast—testing features, rolling back bugs, reviewing each other’s code, even building side-by-side on the same project. It’s speed and safety. And with platforms like GitHub, collaboration doesn’t stop at your team. Open-source projects thrive, freelancers sync with clients, and hard problems get solved in the open.

Getting Git Up and Running

Before anything else, you’ll need to install Git. It’s the backbone of version control, no matter what you’re building. Here’s how to get started across major operating systems:

Windows

Head to git-scm.com/download/win. The download starts automatically.
Run the installer. Stick with the default settings unless you know exactly what you’re doing.
When you reach the “Choosing the default editor” screen, pick one you’re comfortable with. (VS Code is a solid choice.)

macOS

If you have Homebrew, just run:
No Homebrew? You can download the macOS installer at git-scm.com/download/mac.

Linux

The command depends on your distro:

Debian/Ubuntu:
Fedora:
Arch:

Check Installation

Once installed, open a terminal and run:

You should see something like git version 2.41.0. If that comes back clean, you’re good.

Configure Username and Email

This part matters. Git tags every commit with your name and email. Set them like this:

Swap in your real name and email. These will show up in your project history.

Done. Git is installed, configured, and ready to track your next big thing.

Before anything else, you’ll need to set up a new project folder. This is where all your code—and your Git history—will live. You can create one with a simple command:

Once you’re inside the folder, run git init. This may feel like a small step, but under the hood, it’s setting up a full version control system. Git creates a hidden .git directory that stores everything Git needs to track changes: commit history, branches, and more. From that moment on, Git is watching you—but in a good way.

Let’s get some files into the mix. Start by creating a file, maybe intro.md, and save your first few ideas. To prep it for commit, run:

This stages the file. Think of it like marking something for shipping—it’s not sent yet, but it’s ready to go. You can keep staging more files as needed.

Finally, lock in your changes with a commit:

That message will stick with the snapshot forever, so make it clear but concise. Boom—your first tracked step in the project’s history. From here, you’re not just making files. You’re building a timeline you can reference, rewind, or build on—one commit at a time.

git status, git log, git diff, and git checkout aren’t just commands—they’re habits. These four are the daily toolkit for anyone working with Git.

Start with git status. It’s your radar. It shows what’s staged, what’s changed, and what’s untracked. You check it constantly because it keeps you grounded in what’s actually going on.

Then there’s git log. Think of it as your project’s journal. Every commit, message, timestamp—it’s all there. Whether you’re tracking down a bug or just trying to remember who changed what, git log gets you the context.

git diff is your preview mode. Before committing, it shows you exactly what’s different between changes. No surprises, no finger-crossing during commits.

And git checkout lets you time travel. Want to jump to a different branch or roll back to a specific commit? This is how you do it. It’s not flashy, but it’s powerful.

Master these four, and you’re getting the gist of Git without the fluff. Keep it simple, keep it sharp.

How It Fits into Agile Workflows — and What’s Next

Designed for Fast Iteration

Whether you’re building a digital product at scale or prototyping a side project, modern design tools are evolving to fit seamlessly within agile methodologies. This is especially relevant for workflows that prioritize frequent testing, fast iterations, and collaborative input across teams.

Figma and similar platforms allow for real-time changes and stakeholder feedback
Design tokens and shared styles help maintain visual consistency across sprints
Rapid prototyping reduces handoff friction between developers and designers

Collaboration Across Roles

Agile teams thrive on cross-functional collaboration. From designers to devs, everyone benefits from a shared design system:

Developers can reference up-to-date assets and specs instantly
Product teams can adjust requirements mid-sprint with minimal disruption
Designers can easily test different UI approaches without disrupting the core library

Next Steps: From Design to Deployment

Getting beyond beautiful mockups means integrating your design system with the rest of your delivery pipeline. Here’s how to take the next steps:

Implement CI/CD workflows: Automate testing your design system as you go via tools like GitHub Actions
Link with version control: Store changes in Git to track updates, branches, and rollbacks
Use release tagging: Roll out new versions of components with clear version history—just like any production software

Getting Started with GitHub Repos

Creating a new repository on GitHub is simple. After logging in, click the green “New” button on your repositories dashboard. Give your repo a name, like my-vlog-utils, and choose whether you want it to be public or private. That choice matters more than it seems: public means anyone can see your code, private means only you (and invited collaborators) can.

Once it’s created, you’ll get a repo URL—hang onto it.

Now, if you’ve already got a local project folder, crack open your terminal. Navigate into your project directory and run:

git init

This boots up git tracking locally. Then, you’ll connect it to the GitHub repo:

git remote add origin https://github.com/your-username/my-vlog-utils.git

Now it’s time to push your first commit. Stage and commit your files if you haven’t already, then run:

git push -u origin main

That tells git to push your code to GitHub and remember this as the default upstream. From here on, git push is all you need.

You’re in the game.

Git Mastery Starts With Everyday Practice

Version control isn’t something you learn all at once—it’s a skill built through repetition, mistakes, and real-world use. Whether you’re an experienced developer or just starting out, daily interaction with Git helps deepen your understanding and confidence.

Why Daily Git Use Matters

Working with Git regularly exposes you to common workflows, edge cases, and situations you can’t plan for in tutorials. The more you interact with branches, commits, merges, and stash operations, the more second nature they become.

Key habits to build:

Commit early and often—write meaningful messages
Branch for features or fixes before every change
Pull and rebase regularly to avoid conflicts
Explore the Git log and diff to trace what changed and why

Mistakes Are Part of the Process

If you’ve ever broken something with Git—good. That means you’re actually using it.

Recovering from a botched merge or force push is where real learning happens. These moments teach problem-solving, and they help you understand what each command truly does.

When things go wrong:

Use git log and git status to assess the situation
Try git reflog to backtrack and recover old states
Avoid panic; almost everything in Git can be reversed

Keep Practicing

There’s no substitute for doing. Open a new side project, contribute to open source, or just version your notes. Every Git operation you run adds to your fluency.

Git mastery is not about knowing every flag or command—it’s about understanding how to navigate, repair, and maintain your work with confidence.

Working with a Git Repository: Cloning, Committing, and Staying in Sync

Getting started with Git usually begins with cloning a repo. You’ve got two main options: HTTPS or SSH.

Use HTTPS if you’re looking for the quicker setup—just copy the repo URL and use git clone https://.... It works fine, but you’ll probably be entering your credentials more often. SSH, on the other hand, is more secure and less annoying long-term. Once your keys are set up, you can clone using git clone [email protected]:user/repo.git and forget about password prompts.

After that, making changes is straightforward. Edit your files, then run git add to stage them, git commit -m "Your message" to save locally, and finally git push to send everything to the remote.

But here’s where it gets real—teams move fast. So before pushing, it’s smart to run git pull to grab any upstream changes. If your work doesn’t collide with others’, it’ll just merge quietly. If conflicts pop up, Git tells you where things broke. Fix them in your editor, mark as resolved, and commit again.

This is the core loop: pull, change, commit, push, repeat. Whether you’re solo vlogging or part of a bigger content team, getting comfortable with this cycle keeps everyone in sync and your content pipeline flowing.