But beyond repositories and commits, your profile can say a lot about you as a developer.

When used intentionally, GitHub becomes more than a code hosting platform. It becomes your CV for your codebase. It tells your story, showcases your skills, and gives people a reason to trust your work.

In this article, we'll break down the different ways to make your GitHub profile stand out. From setting up your GitHub account to engaging storytelling for your repositories, there's lots you can do.

Let's get started!

Table of Contents

• Sign Up for a Github Account

• Add a Profile Image

• Add Profile Details

• Add a Profile README File

• Tell a Story About Each Repository

Step 1: Sign Up for a Github Account

To begin, you'll need a GitHub account. If you don’t have one, you can set one up here.

Once you have your account set up and you're logged in, we can move on to the next step.

Step 2: Add a Profile Image

Your profile image is often the first thing people notice. It could be a professional photo of yourself, or an image or avatar that represents you or your interests

As long as it’s appropriate, you’re good to go.

To add a profile image, you'll need to:

• Open your profile menu/dashboard

• Click on the image icon at the left

• Click on the edit text on the image icon

• Select the image to set as your profile picture

• Click the "Set new profile picture" button

So, you should have something like this:

GitHub link to this page: https://github.com/settings/profile

And there you have it, your GitHub profile image is set.

On to the next one…

Step 3: Add Profile Details

This step is all about credibility and discoverability.

At the center of your profile settings you'll see fields like email, location, social media links and so on. We'll be adding those details so you can take advantage of the discoverability it lends to your profile.

GitHub link to this page: https://github.com/settings/profile

For this step, you'll want to add as much detail as possible (apart from your home address – I think we both know why).

For the location, you can just put in your city or country so others have a general idea of where you are in the world.

Step 4: Add a Profile README File

This is where you introduce yourself properly and tell your story.

A Profile README is a special repository named exactly the same as your GitHub username. Your README file appears directly on your profile page.

The READme should answer the following questions:

• Who are you?

• What are your project highlights?

• What are you currently working on or learning?

• Your hobbies or interests (optional)

While answering these questions, you should aim to keep it minimal and yet interesting. You don't want to overwhelm the visitor.

Here's how to create your README:

• Click New repository

• Name the repository exactly the same as your GitHub username

• Check “Add a README file”

• Make sure the repository is public

• Click Create repository

Profile README file setup:

GitHub link to this page: https://github.com/new

So if you answered the questions listed above, your README file should look something like this:

GitHub link to this page: https://github.com/chinazachisom/chinazachisom

It should also be showing directly on your GitHub profile like below:

GitHub link to this page: https://github.com/chinazachisom

Step 5: Tell a Story About Each Repository

Now, this is where you can tell a story about each of your repositories using a README file.

NB: Each repository should have its own separate README file.

What to include in a repository README:

• Project title

• What the project is

• The purpose (the “why”)

• Key features

• Challenges you faced and how you solved them

• Setup or usage instructions (or a live link if hosted)

• Technical concepts used (e.g., throttling, caching, lazy loading) (optional)

• Images or video demos

You may also include badges, charts, contribution graphs or other visual enhancements that help highlight project quality, activity and impact.

With the above structure, you can tell the stories behind your projects, show your problem-solving skills, and make your work easier to understand and evaluate.

Repository README File Sample:

GitHub link to this page: https://github.com/chinazachisom/Artsy

Conclusion

Your Github Profile is more than just a storage space for your codebase. It's your developer Identity as well.

Following these basic steps can help turn your Github into a portfolio infused with your personal brand. It makes your GitHub Profile stand out, which can help open doors for more opportunities.

Treat it like a CV for your code and let your work speak for you.

About the Author

Hi there! I'm Chinaza Chukwunweike, a Software Engineer passionate about building robust, scalable systems that make a real world impact. I'm also an advocate for continuous learning and improvement.

If you found this useful, please share it! And follow me for more Software Engineering tips, AI learning strategies, and productivity frameworks.

Curious about the hype I saw on Bluesky, I recently joined the npmx Discord server on a whim. My journey from lurker to contributor taught me a lot about OSS and gave me new confidence going into code reviews.

In this article, I’ll walk you through my journey to give you a little insight into the process of getting involved in Open Source.

Here’s what I’ll cover:

• My Struggles with Pull Requests

• My Former View of OSS

  • The Basics of OSS

  • The Dark Side of OSS

• Getting Started with npmx

• The Not So Perfect PR

• Collaboration Over Perfection

• My Current View of OSS

• Tips for PR Authors and Reviewers

• Conclusion

My Struggles with Pull Requests

I’ll admit, I’ve always had a hard time with code reviews. I can be quite the perfectionist. I’ll entertain every nitpick and only hear the criticism.

If reviews go on for days, I easily get overwhelmed. I enjoy pairing and co-working. I want to enjoy Pull Request (PRs), but addressing PR comments takes a lot out of me.

Some of my struggle is a need for accommodations that I rarely get. I also have plenty of lived experience with how hostile code reviews can become (even in a professional setting). Finally, there’s how I was introduced to PR reviews.

Outside of work, I had only ever experienced perfunctory PRs – I’d receive at most one suggestion, but usually just got a “LGTM” (Looks Good to Me) comment. Professionally, I went from no code reviews to incredibly detailed code reviews basically overnight. I still feel like I’m playing catch up.

On the one hand, thinking deeply about every suggestion has made me a better developer. I thrive in collaborative environments with thoughtful code reviews. Developers who have worked with me have told me that they benefit from answering all my “why?” questions.

On the other hand, I demand compliments, gifs, and video calls from my reviewers. I don’t do well with a bombardment of vague comments on my PRs. I’ve spent a lot of time documenting code guidelines and review processes that other people seem to understand and remember much more easily than I do.

Developer communities have helped me navigate all of this. Community is a priceless resource for career changers and new grads. When everyone shares their experience, the uninitiated learn about how things could be and what kinds of things aren’t normal (like very hostile code reviews).

My Former View of OSS

When I’ve talked and written about developer community, I’ve recommended online networking communities, going to meetups, tech conferences, social media, writing, and posting your writing online. The one thing I haven’t written about? OSS.

My first real introduction to OSS was through the online networking group Virtual Coffee. By the end of my first Hacktoberfest, I knew the basics.

The Basics of OSS

• Find a project that interests you.

• Check the Contributing Guide.

• Claim an issue.

• Following the Contributing Guide, make a fork, write the code, and open a PR.

• The maintainer merges it.

• You did it! That’s OSS.

The Dark Side of OSS

Over time, I couldn’t help but see the “dark side” of OSS – maintainers burning out, friction between users and maintainers, corporations suddenly trying to assert control over OSS (for example, Wordpress, Ruby), and the thankless, frustrating job of maintaining a package that everyone uses but no one wants to pay for.

I have to be honest: I had begun to think of open source maintainers as Roz from Monsters Inc. – justifiably fed up with the extra work dumped on them by unappreciative people.

Meeting maintainers in-person didn’t contradict my view. Every single one had a story about burnout and lack of funding. I started to assume that anyone excited about OSS just hadn’t been in it long enough

…so my friends were quite surprised when I suddenly announced that I had joined the OSS project npmx.

Getting Started with npmx

It wasn’t the first mention of the npmx project that interested me. It wasn’t the second. It was a meme. I’ve known Daniel Roe long enough to know that he is brilliant. I like learning from people who are smarter than I am.

I reached out to Patak, and got an invite to the npmx Discord server. I was amazed by what I saw: a rapidly growing, excited, and inclusive community. I realized that I had only ever contributed to communities with at most a handful of people. My view of OSS immediately changed.

This was it. I was finally going to have fun doing PRs.

So I hopped into the npmx GitHub repository and tried to get my bearings. Very quickly, I was overwhelmed. The project moves so fast. I tried to do step 3 – claim a ticket. As far as I could tell, all the tickets were being claimed in Discord before or as they were being written.

Jono kindly welcomed me into his fork for working on the blog page, but I ran into frustrating and weird issues with running the repository (repo) locally and the pre-commit hooks. Multiple people tried to help me debug and were just as stumped as I was.

The next day, Salma arrived. The day after, she was in charge of outreach, and asked me to write a blog. Then life got in the way. I couldn’t keep my promise to context switch into a feature branch in a new repo. I felt like my only contribution was going to be a single line change on the blog page and a blog.

It didn’t help that I wasn’t happy with the blog I had started writing. I gave up on keeping up and lurked in the Discord channels. I chimed in on a few conversations, and offered to help with things like failing accessibility tests.

Four days later, the project was officially two weeks old. The maintainers announced a mandatory week of vacation – community members experienced with burnout had seen the writing on the wall. Vacation would start in 10 days, so that’s basically how long I had to get a contribution in before the alpha release.

The Not So Perfect PR

An hour later, I finally saw it – my chance to contribute code. Alex needed a toggle re-written as a checkbox. It was my time to shine. I commented on the ticket to claim it as soon as it was written. I slapped up a draft PR to show I was working on it. Predictably, my focus was once again pulled away from the repo.

A couple days later, Knowler reviewed my draft PR, and all my PR anxieties came tumbling back. This was going to be The Perfect PR. How dare anyone look at it before I was ready to defend my work. What would they think about my abilities looking at my old copy and pasted portfolio site code that I hadn’t even finished translating from React to Vue? I was legitimately embarrassed someone was looking at my code in that state.

Fueled by embarrassment and productive procrastination, I sprung into action. In what little free time I had, I must have toggled my toggle a thousand times. Three days later, it was finally in a state I was happy with. It was time to open up my PR for review.

A couple dozen comments came in. Overwhelmed, I tried to remember that I had asked for this. I resolved most of the comments and left a comment saying I’d get to the last item, forced colors mode, in the morning. Frustrated with the code for the forced colors and myself for forgetting a few tiny things, I went to play games with friends.

A few hours later, I got a DM from Daniel. He had some code for my PR. I agreed with his reasoning for all the changes and found out an entire tooltip had been added while I was blissfully ignoring the rest of the repo. (I’m confident in my ability to merge or rebase my way out of any situation.)

Splitting my attention between Enshrouded and talking to Daniel, I felt defeated. I knew I finish the forced colors fix the next day, but also adding a tooltip felt daunting. Still, it felt like I needed to do it all.

Collaboration Over Perfection

And then I remembered, this wasn’t work and it wasn’t going to come up on a performance review. I wasn’t alone – Knowler and Daniel were taking the time to help me get this PR merged because they wanted to. I had the opportunity to collaborate with some brilliant people and see how they would write the same thing.

So I pushed through my perfectionism, demanded compliments, and asked Daniel to push his changes. I told him I’d review them in the morning.

Reviewing Daniel’s code, I found that he had forgotten a couple tiny things, just like I had. The code I was frustrated with the night before was legitimately frustrating. Emulating forced colors on a Mac was giving me weird and contradictory results. I needed to test on a Windows machine to finally get it right.

Then, six days after I opened the PR, I finally merged it. I was on top of the world. I had gotten my contribution in before our vacation (and more importantly, I had received multiple compliments). Finally, I knew what to write this blog about.

My Current View of OSS

When you’re looking for a project that interests you, the code isn’t the only thing to evaluate. Early in my career, I learned three rules for evaluating software tools.

1. Check the date of the last update to make sure it’s actively maintained.

2. Look at the documentation. Is it up to date and easy to follow?

3. Check out the community. Do people get fairly quick responses to their questions?

After joining npmx, I’ve discovered that, with a few tweaks, these rules also apply to evaluating an OSS project.

1. Check out the last few tickets and PRs to see how fast the repo moves. If it’s fairly slow, you can probably claim an issue in GitHub easily. If it’s rapid, start by getting to know the community and how they’re assigning tickets.

2. You should always check the repo for a code of conduct, contributing guide, and sufficient documentation. Also evaluate the tickets. Are contributors expected to research solutions on their own or given strict requirements? How do maintainers respond to comments on issues?

3. Check out the community. An active, inclusive community makes contributing a lot more fun.

Now, my view of OSS is much more nuanced. Yes, there are issues with OSS as whole, but there’s a reason people want to fix them. OSS can be collaborative, inspirational, and enjoyable.

Tips for PR Authors and Reviewers

People underestimate the importance of the relationship between PR author and reviewer. A collaborative OSS code review process doesn’t happen in a vacuum. It takes careful cultivation by the PR author, PR reviewer, and project community.

For a long time, I focused on the responsibility of the reviewer to make the PR author comfortable (for example, compliments, gifs). Don’t get me wrong – I think one of the most important parts of a senior developer’s job is to provide constructive, actionable feedback.

But I now understand that the PR author’s sense of agency and desire to learn are just as important.

A sense of agency is a sense of control over actions and consequences. In other words, the PR author needs to feel that they have control over what goes into their PR. Before npmx, I understood this a little bit. I always ask “why?” because I’m not putting my name on code that I don’t understand and agree with. I have counseled my own junior developer that it’s his job to get PRs he’s authored reviewed and merged.

After experiencing an in-depth code review outside of work, I finally understand that a PR is a process. Reviews exist to get consensus, so “perfect” is far more subjective than I originally thought. There’s a reason you get a conversation, not a grade.

Maybe I’ll even ignore some nitpicks in the future.

A desire to learn makes remaining open to a reviewer’s suggestions and requests a lot easier. During my first npmx PR, it was only when my desire to learn outweighed my desire to prove something that I started having fun.

Conclusion

Today, March 3rd, 2026, is the alpha release of npmx, and I am very proud to be a contributor and member of the community.

I look forward to learning about OSS from Patak, fancy, smart code from Daniel, outreach from Salma, and accessibility from Knowler. I know I’ll learn many things outside of that list, too. I’m grateful I’m not the smartest person in the room and that I finally get to have fun with Pull Requests.

In an ideal setting, you would write code for a feature, add that code to the staging area, and then commit it before going to the next part. This helps keep your commit history clean. (Don't worry if you don't have a clean history. Many of us don’t.)

But now, imagine a scenario where you have multiple features to build. You've committed the first. You've started the third, but then you found out you needed to build the second one first, because the third depends on it. It might seem like you have to go back in time and build out that second feature without mixing in the code changes for the third, and without deleting the code changes for the third.

So how do you do that?

In this article, you’re going to learn about Git stash, what it is, and the basic commands you need to be able to use it.

What We’ll Cover:

• What is Git Stash?

• How to Use Git Stash

  • Pushing Commands To The Stash

  • Applying Changes From The Stash To The Working Directory

  • Listing The Items In The Stash List

  • Removing Items From The Stash

  • Creating A New Branch From Stash

  • Showing The Changes In The Stash

• Conclusion

To understand and get the most out of this tutorial, you’ll need to have a basic understanding of Git.

What is Git Stash?

Git stash provides storage (in the form of a stack) where you can store changes to your code. It lets you keep these changes separate from the current working directory until you're ready to apply them.

git stash is a relatively simple command, and has a few variations like:

• git stash push

• git stash pop

• git stash apply

• git stash drop

• git stash clear

• git stash show

• git stash list

How to Use Git Stash

Pushing Code Changes to the Stash

To push uncommitted changes from the working directory to the stash, you can use git stash push. When you do that, the changes disappear from the working directory and are saved in the stash. The working directory is then set back to the last commit (which, in the example below, is the Feature one).

git stash push

You can also write the git stash push command as just git stash – it means the same thing and performs the same way. You can also add a message to it with the -m or --message flag:

git stash push -m "Feature two I was working on"

You can use the -u flag or --include-untracked to include untracked changes in the stash. This way, the changes not yet tracked by Git can be included in the stash.

git stash push -u
git stash push --include-untracked

On the other hand, you can decide to push only staged changes to the stash with the -s or --staged flag:

git stash push -s

You can also suppress feedback messages with the -q or --quiet flag:

git stash push -q

When you're done with your edits on the current working directory, you can commit and push without the older changes bleeding into it. They're safely stowed away in the stash.

Anytime you use the git stash command, you add a stash to the stash list. The stashes are identified by their index numbers.

Applying Changes from the Stash to the Working Directory

Let’s say you had a quick fix to do. You’re done committing that, and you want to continue with what you were working on. You can restore the changes from the stash to continue working on them.

You can do this by using the git stash apply command or the git stash pop command:

git stash apply

git stash apply applies the latest changes from the stash to the working directory, but doesn’t delete the code from the stash. You can select a particular entry to apply by index number:

git stash apply --index stash@{1}
# You'd need to use quotes "stash@{1}" if you're writing this in PowerShell

git stash pop, on the other hand, applies the latest changes from the stash, then deletes them from the stash. Basically, popping from a stack. You can select a particular stash entry to pop by index number.

git stash pop

git stash pop --index stash@{1}
# You'd need to use quotes "stash@{1}" if you're writing this in PowerShell

Listing the Items in the Stash List

You can use git stash list to list out the stashes in the stash list. It’s arranged by index number (like {0}, {1}, and so on). Any time you do a git stash push, it adds a stash to the stash list.

git stash list
stash@{0}: WIP on master: b2a2709 Feature one
stash@{1}: WIP on master: b2a2709 Feature one

Removing Items from the Stash

You can use git stash clear to clear the stash list. But if you just want to drop a particular entry from the stash list, you can use git stash drop and specify the entry you want to drop by the index number. This doesn’t apply its changes to the working directory.

git stash clear

git stash drop stash@{0}
# You'd need to use quotes "stash@{0}" if you're writing this in PowerShell

Creating a New Branch from Stash

You can also create a new branch from a stash using git stash branch. The syntax is git stash branch <branchname> [<stash>].

git stash branch premium-branch stash@{0}
# You'd need to use quotes "stash@{0}" if you're writing this in PowerShell

If you don’t add the stash index, it will just use the last stash.

git stash branch premium-branch

Showing the Changes in the Stash

You can use git stash show to show the changes you’ve made in your stashed changes.

C:\file-path\git_stash_example> git stash show
 text.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Conclusion

Git stash is one of those quiet tools that becomes indispensable once your workflow starts to get messy. It allows you to shelve unfinished ideas, switch context without panic, and keep your commits clean. With it, you can safely carry out urgent fixes, and juggle dependent features without muddling up your commit history.

If you enjoyed this article, share it with others. You can also reach me on LinkedIn or X.

To start, let’s clear one thing up: Git and GitHub are not the same thing.

In short, Git is the tool that runs on your own computer and keeps track of changes in your files, while GitHub is an online platform that lets you store those Git projects in the cloud and collaborate with other people. Git works perfectly fine on its own, but GitHub makes teamwork, sharing, and backup much easier. They’re connected, yes, but completely different.

Think of it this way – Git is the “coffee,” and GitHub is the “coffee shop” where that coffee is served. Fun analogy, right? Don’t worry, in just a moment you’ll see exactly what that means.

What Does Git Do?

So, let’s start by understanding what Git actually is and how it works. Simply put, Git is a powerful tool that constantly keeps track of every change you make to your files - and I mean literally all the time. Day or night, 365 days a year, Git records what changed, when it changed, who changed it, and even where it happened.

Now, what kind of files are we talking about? Almost any kind – not just code. It could be an image, a text file, JavaScript, PHP, Python, or even a video. No matter what you’re working on, Git tracks every single change. Pretty amazing, isn’t it?

But here’s the best part: the magic of Git doesn’t stop there. The coolest thing about Git is that it saves different versions of your files. Imagine you wrote some code and then made a few changes to it after a few days. Now you want to make sure the old version doesn’t get lost. That’s exactly where Git comes to the rescue. It lets you keep multiple versions of the same file effortlessly, and whenever you want, you can roll back to any previous version in just a moment.

By the end of this handbook, you’ll not only understand what Git and GitHub are, but you’ll also be able to use them confidently in real projects. You’ll learn how Git tracks changes locally, how repositories work, how to move changes through Git’s workflow, and how to collaborate with others using GitHub.

We’ll start from the very basics and gradually move toward more advanced concepts like branching, merging, resolving conflicts, and safely undoing mistakes – all with hands-on examples you can follow along with.

Here’s What We’ll Cover:

1. Prerequisites

2. What is Git?

   • Git vs GitHub

3. Git Architecture – Local and Remote

4. How to Install Git on Your Computer

5. How to Create a Project and Initialize a Local Repository

6. How to Create a Remote Repository on GitHub and Clone It

7. How to Track Changes with git status

8. How to Move Changes to the Staging Area with git add

9. How to Save Work Permanently with git commit (and Configure Git)

10. How to Delete and Restore Files with git rm and git reset

11. How to View Commit History with git log

12. Branching and Merging in Git

    • Understanding Merge Conflicts

13. How to Navigate History with git checkout and Compare Commits with git diff

14. How to Work with Remotes: git push, git fetch, and git pull

    • Example – git push

    • Example – Pushing Other Branches

    • Example – git fetch

    • Example – git pull

15. How to Undo Local Changes with git restore

16. How to Temporarily Shelve Work with git stash

17. How to Undo Commits Safely with git revert

18. How to Keep History Clean with git rebase

19. How to Collaborate on GitHub with Pull Requests

20. Git & GitHub – Concise Summary

    • Git vs GitHub

    • Core Git Architecture & Workflow

    • Getting Started

    • Seeing & Moving Changes

    • Deleting, Restoring & Undoing

    • Branching, Merging & Conflicts

    • Navigating & Comparing History

    • Working with Remotes (GitHub)

    • Temporarily Shelving Work with git stash

    • Keeping History Clean with git rebase

    • Collaboration with Pull Requests (PRs)

    • Big Picture Takeaways

21. Final Words

Prerequisites

• Basic File & Folder Navigation – Using Finder / File Explorer.

• CLI Usage – Running simple commands in Terminal or Command Prompt.

• Text Editor – Any editor for opening and editing files.

I’ve also created a video to go along with this article. If you’re the type who likes to learn from video as well as text, you can check it out below:

What is Git?

Git is most commonly used in coding projects, but its power goes far beyond just code. You can use Git to keep track of changes and maintain different versions of almost any file. This means you never have to worry about losing a file or accidentally overwriting something important.

Let’s look at a real-life example. Suppose you’re working on a project. You’ve spent hours writing code, your client loves it, and everything’s going great. Then, a month later, the client asks for some new changes. You make the updates as requested. But after a few days, the client comes back and says, “Actually, the old version was better.” Now you’re in trouble, right? Because you’ve already overwritten the original code. How do you get it back?

That’s exactly the kind of problem Git solves. This is why Git is known as a Version Control System – it keeps every version of your files or code safely stored, so you can go back to any previous state whenever you need to, without losing a thing.

Git was created by Linus Torvalds – the same brilliant mind behind Linux. And honestly, what he built is nothing short of genius. Most tools programmers use have a short lifespan, but Git is one of those rare ones that, once you learn it, stays useful for the rest of your career.

The best part? The basics of Git aren’t that hard to learn at all. It’s built around a few simple commands and concepts, and once you understand those, the whole system starts to make perfect sense.

Still, for beginners, Git can feel a little confusing at first – and that’s exactly why this handbook exists. Think of it not just as a tutorial, but as a complete learning resource for learning Git inside and out. We’ll cover all the essential topics you’ll actually use in real-world projects. And if you want to jump to a specific topic, you can easily find it by using the section headings in the table of contents after the intro.

If you follow this tutorial closely, you’ll be able to understand every part of Git, step by step.

Git vs GitHub

Now, let’s move on to another important topic: the difference between Git and GitHub. Git is a tool that runs locally on your own computer. It tracks all the changes you make to your files and keeps everything organized.

But imagine this: you and your teammate are working on the same project. You’re coding on your own computer, and your teammate is working from another one. That means you both have different versions of the same project, right? And if your team has more members, there will be even more versions – each saved separately on their own machines.

This is exactly where GitHub comes in. When the project is complete, you’ll need to combine everyone’s work into one place to merge all those changes together. For that, you need a central hub where everyone can upload their updates. You push your work there, your teammate pushes theirs, and GitHub brings it all together.

GitHub acts as that central online server where your team’s entire project lives, making it easy for everyone to see, edit, and share updates in one place, without any confusion.

But GitHub isn’t the only place where you can host your Git repositories. There are other popular platforms too, like GitLab and Bitbucket. These are also widely used and trusted by developers around the world. Still, among all of them, GitHub remains the most popular and widely adopted platform.

That’s why in this tutorial, our focus will mainly be on GitHub. It’s now owned by Microsoft and is maintained with great care and attention. Especially in the programming community and in the world of open-source projects, GitHub’s contribution is truly remarkable.

So without wasting any more time, let’s dive in and explore how Git and GitHub actually work – and see some real-world use cases that will help you understand their power in action.

Git Architecture – Local and Remote

Before you start working with Git, the most important thing is to understand its core concept: how it actually works and what its internal structure, or architecture, looks like.

Git is mainly divided into two major parts, Local and Remote.

• The Local part refers to your own computer, where you do all your work. This is where your files, code, and every change you make are stored.

• The Remote part, on the other hand, lives in the cloud. It’s where you push or upload your local work. In most cases, when you say “remote,” you’re usually referring to GitHub.

Now, let’s start with how the local part works. On your computer, the folder where you’re working on your project is called the Working Directory. This is where all the action happens: you write code, create new files, modify existing ones, and make changes as needed. And when you feel like, “Alright, this version looks good, I want to save this change,” that’s when you move on to the next stage in Git’s workflow.

So, what do you do next? You move your work to the “stage.” At first, this word might sound a bit unfamiliar, but once you use it a few times, it’ll make perfect sense. In simple terms, when you finish your work in the working directory, staging means you’re saying, “Alright, my changes are ready – they can move to the next step.” This staging process is the second phase in Git’s workflow.

Then comes the third phase where you take the staged files and send them to the local repository. You can think of the staging area as a middle ground – a temporary space where files sit between your working directory and the final save in the repository.

Once you’ve reviewed everything and you’re confident the work is correct, you “commit” it. Committing means permanently saving those changes to your local repository – that is, locking them in as a recorded version of your project’s history.

Now you might be wondering, what exactly is a repository? Simply put, a repository is a place where all the versions of your files and their complete change history are stored. In the case of a local repository, it’s a specific folder on your own computer. For a remote repository, it lives on a cloud server, like GitHub.

You can think of a repository as a digital cabinet for your code. It’s a secure place where Git neatly stores every record of your work and every change you’ve ever made. Inside this repository, Git automatically creates a few system files that track everything – your changes, history, commits, and more. These files are managed entirely by Git itself, and the whole system runs based on the data stored within them.

So if we summarize everything so far, it goes like this:

1. You work inside your local working directory.

2. Once you’re done, you stage your changes.

3. Then you commit those staged files to the local repository.

Up to this point, everything happens only on your own computer – nothing has been sent to the cloud yet. You need the cloud only when you want to share your code with others, access it from another computer, or keep it safely backed up.

That’s when you “push” your local repository to the remote repository. In other words, you upload it to GitHub. Think about it like this: just as you use Google Drive or OneDrive to store files, photos, or documents, you could technically keep everything only on your own device. But you store them in the cloud so that you can access them from anywhere, and even if something gets deleted locally, it stays safe online.

GitHub works the same way. It’s your cloud backup for code. So you see, the main purpose of this whole process is to make collaboration and remote access possible. Having a remote means you can easily send your code from the local repository to a cloud server, and if needed, pull that same code back to any other machine.

That’s the core idea of Git, and the foundation of the entire system rests on this simple concept. Beyond that, there’s nothing overly complex. Once you clearly understand this basic workflow, everything else in Git will feel much easier to grasp.

How to Install Git on Your Computer

Now, let’s see how to get started using Git from scratch.

The very first step before working with Git is installing it on your computer. It might already be installed on your machine, so just check first.

If you do need to install Git, you can download it directly from the official website. There, you’ll find different versions for the three major operating systems – Windows, macOS, and Linux. Simply choose the one that matches your system, and you’ll get clear download instructions right there.

If you’re on Windows, click on the Windows option, and you’ll see two download choices: one for 32-bit and another for 64-bit systems. Just pick the one that matches your setup, download it, and run the installer.

For Mac users, when you select the macOS option, you’ll also find instructions on how to install Git using Homebrew. Just follow those steps, and your installation will be done in no time.

And for those using Linux or other Unix-based systems, you can follow the installation guide provided on the site according to your distribution. The entire process is simple and straightforward.

Once you have Git installed, the next step is to open your terminal or command prompt. If you’re using a Mac, open the Terminal app. For Windows users, you can use either Command Prompt or PowerShell – both will work just fine.

But after installing Git, you’ll usually get a separate terminal called Git Bash. You can use that too if you prefer. Many developers like working in Git Bash because it feels very similar to a Linux terminal and makes running Git commands easy and intuitive.

On Windows, you can open Git Bash by right-clicking anywhere inside a folder and selecting “Git Bash Here”.

You can also open it by searching for Git Bash from the Start menu.

When it opens, you’ll see a terminal window that looks very similar to a Linux or macOS terminal, with a dark background and a command prompt ready to accept Git commands.

For the rest of this tutorial, I’ll be using macOS with the default Terminal app, but the Git commands themselves are exactly the same on Windows (Git Bash) and Linux. If you’re using Windows or Linux, you can follow along using your terminal of choice – only the way you open the terminal may differ slightly.

So now open your terminal. The first thing you need to do is make sure Git is properly installed, right? To check that, type a simple command in the terminal:

git --version

Then press Enter. As soon as you do that, you’ll see an output on the terminal showing the version of Git installed on your machine. Keep in mind that the version number might not be the same for everyone – it depends on when you installed Git and which update you’re using.

If Git is installed correctly, you’ll see this version output. But if it isn’t installed, you’ll get an error message instead. Hopefully, Git is now properly set up on your machine, and you’re ready to start using it.

How to Create a Project and Initialize a Local Repository

Now it’s time to get hands-on and do some practical work. As I mentioned earlier, Git can be implemented in any file or folder, right? So first, you need to create a few files and folders to work with.

Start by navigating to the desktop using the terminal:

cd ~/Desktop

Here, cd is a terminal command that stands for “change directory.” It simply means you’re moving from one folder to another. Hopefully, you’re already familiar with some basic terminal commands like cd, pwd, touch, and mkdir. If not, you can easily learn them using Google or tools like ChatGPT. They’re simple to understand.

Just remember, for Windows users, some of these commands might be slightly different. And keep in mind, commands like cd, pwd, touch, and mkdir are general terminal commands – not Git commands.

Now that you’re inside the Desktop directory, create a new folder where you’ll keep all your project files. Name it git-one:

mkdir git-one

Press Enter. You’ve now created a new folder named git-one inside the Desktop directory. Move into that folder like this:

cd git-one

You’re now inside the git-one folder, and this is where your Git project begins. Inside the git-one folder, create two files:

touch one.txt
touch two.txt

Next, create another folder named myfolder:

mkdir myfolder

Then use cd myfolder to enter the folder. Inside this folder, create another file:

touch three.txt

Now check everything you’ve created in your file system. On macOS, for example, you can open the git-one folder in Finder by running:

open .

Here, the dot means “the current folder.” As soon as you press Enter, Finder opens up. Inside the git-one folder, you’ll see two files, one.txt and two.txt, and a folder named myfolder, which contains the three.txt file.

Now write something inside each of the files. Open one.txt in a text editor, write one, and save it. Then open two.txt, write two, and save that as well. Finally, go inside the myfolder directory, open three.txt, write three, and save it. Now all three files contain some content.

This git-one folder is your working directory. As mentioned earlier, this is the folder where you’re doing all your work, and where all your files are stored.

If you want Git to start monitoring everything inside this git-one folder, you have to tell Git, “This is my project folder. Track all the changes here.” To do this, go back to the terminal, make sure you’re inside the git-one folder, and type this:

git init

The word init means “initialize.” In other words, you’re telling Git to start working inside this folder from now on. Once you run the command, it shows a message: “Initialized empty Git repository.” That means Git has now started tracking this folder.

So how do you know that? Since you’re inside the git-one folder, type this:

ls

You’ll see all the files and folders inside it. Now type:

ls -la

Notice that now you can also see a hidden directory named .git. The ls -la command lets you view hidden files and folders.

Operating systems hide certain files and folders by default to protect users from accidentally modifying or deleting critical system data. These hidden files usually store configuration, metadata, or internal information that regular users don’t need to touch. For example, you might see hidden files like .env, .DS_Store, or .config in different projects.

You can see a hidden folder named .git inside your project directory. Who created it? Git did. This .git folder is actually the core of the entire project. It’s where Git keeps all its internal data, such as which files have changed, who made the changes, and what the previous versions were. In short, everything Git does is stored right here.

The .git folder is hidden for the same reason: it contains Git’s internal database and configuration. You normally never edit anything inside .git manually. If this folder is deleted or corrupted, Git loses the entire history of the project. Hiding it helps prevent accidental damage.

From now on, Git will be able to track every change you make in your work. Let’s say you make some changes to the three files you created earlier. That means you now have a local Git repository. By running git init, Git created the hidden .git folder and started tracking this directory as a repository. From this point on, any changes you make to files inside this folder can be staged, committed, and recorded in Git’s history. Even though you haven’t made a commit yet, the repository already exists locally and is ready to track your work.

How to Create a Remote Repository on GitHub and Clone It

You can also create a remote repository directly. I mentioned this earlier, so let’s see how to do it. Open your browser again and go to:

https://github.com

If you’re new, you’ll need to create an account on GitHub first. If you’re already logged in, you’ll see your profile. On the left side, you can see your repositories, feeds, and other details. Your goal is to store your local files on GitHub.

To do that, you need to create a new repository on GitHub. Click the blue New button. Just like you used git init to create a local repository, here you can initialize one in the cloud. Give it a name – for example, git-journey – and in the description, write something like “You are learning Git and GitHub.” Keep it public so everyone can view it. Then click the Create Repository button. You’ve now created a new repository on GitHub.

Right now, the repository is completely empty – it doesn’t have any files in it. To add some files, click the Create a new file button, name it one.txt, and inside the file, write one. Then click the Commit changes button. The term “commit” basically means “save.” Committing is like saving a file – nothing complicated. Don’t worry about this too much now, as I’ll explain commits in more detail later.

For now, there’s already a default commit message saying “Create one.txt,” so you can keep that as it is and click Commit changes. Next, create another file the same way – this time naming it two.txt, writing two inside, and saving it. Now, if you check your GitHub repository, you can see two files there: one.txt and two.txt.

At this point, you have two repositories – one on the cloud (GitHub), and another one locally on your computer. You initialized the local one yourself earlier, but now you want to bring the GitHub repository down to your machine by cloning it.

Go back to your terminal. Suppose you’re currently inside the git-one folder, but you want to clone the remote repository onto your Desktop. In the terminal, type:

cd ../

This command takes you back to the Desktop. Now, you’re going to clone the remote repository – the one you just created on GitHub. For that, you need a link, which is the repository’s URL. Go back to GitHub, open that repository, and click on the Code button. There, you’ll see an HTTPS link. Copy that link. Then, in the terminal, type the following:

git clone <repository-https-link>

Replace <repository-https-link> with the link you just copied, and press Enter. Git pulls your GitHub repository down onto your local machine.

After a few moments, the cloning process is complete. To verify whether the repository has been successfully cloned, type in the terminal:

ls

Remember that this command shows the list of folders in your current location. You’ll see a new folder named git-journey, alongside your previous git-one folder. Enter the git-journey folder like this:

cd git-journey

You’re now inside the git-journey directory. If you type this:

ls

you can see the contents of the folder. Inside it you should see the two files, one.txt and two.txt. To see hidden files, type:

ls -a

You’ll find a .git folder here as well. That proves this is also a complete Git repository, cloned from the cloud. Earlier, you saw the same thing in your local repository, right? So, this is how you can create a Git repository in two ways – one by initializing it locally, and the other by cloning it from GitHub or any other remote server. No matter which way you create it, to start working with Git, initialization is always required.

How to Track Changes with git status

Now let’s look at something new. Suppose you’re currently inside the git-journey folder. This is the repository you just cloned from the remote, right? If you make any changes to this repository – for example, you open the file one.txt in a text editor, keep everything as it was, but add the number 1 at the end and save the file – you might want to know what exactly changed, or whether Git has detected the modification.

To check that, type in the terminal:

git status

As soon as you run this command, Git immediately tells you: modified - one.txt. This means Git has already detected the change you made in that file.

Now let’s say you make a small change in two.txt as well – just adding a 2 at the end – and then run git status again. This time it shows modified - two.txt. That means both files have been changed, and Git has detected both modifications.

This is exactly how Git continuously keeps an eye on every change you make. It’s like it’s always watching over your project. At any moment, you can run the git status command to see which files have been modified or updated.

In a real project, you’ll often work with multiple files at the same time, right? In that case, git status gives you a clear summary of the overall situation: what has changed, which files are new, and which ones are modified.

So, up to this point, you’ve learned that you can initialize Git in two ways – either locally or from a remote repository. And with git status, you can easily check what changes have been made in your working directory.

Now let’s move out of the working directory into the staging area.

How to Move Changes to the Staging Area with git add

So far, you’ve only worked inside the working directory. That means you’ve created and modified files, but you haven’t yet told Git to keep those changes. Now you’re going to move them into the staging area.

In Git’s terminology, the process of moving changes from the working directory to the staging area is called adding. Simply put, git add means telling Git, “I want to keep this change.” Right now, inside the git-journey folder, you have two files, and both have been modified.

Now create another folder inside git-journey, named myFolder:

mkdir myFolder

Use cd myFolder to enter that folder. Inside myFolder, create a new file named three.txt:

touch three.txt

Open three.txt in your text editor, write three, and save the file. Now, you’ve made quite a few changes:

• You created a new folder.

• You added a new file.

• You modified some existing ones.

Your entire project has gone through multiple changes. Go back to the repository’s root folder (the git-journey folder) by running this:

cd ..

From here, check which files have actually been changed:

git status

Git shows that two text files have been modified, and a new folder has been created. Git also says that the old files are “tracked,” while the new folder is “untracked.” Why is that? Because the old files came from the remote repository you cloned earlier, so Git already knows about them. But since myFolder is newly created, Git doesn’t recognize it yet.

If you want to move everything to the staging area at once, you have two options: use git add --all or the shorter version git add -A. Both commands do exactly the same thing. Try it out:

git add --all
git status

Git has staged everything. All the changes you made are now “ready to commit.” You’ll learn more about commits in detail later. For now, just remember that when you use git add --all, Git takes every change and prepares it for the next commit. If you want to go back to the previous state – that is, remove everything from the staging area and return them to the working directory – type this:

git reset
git status

You’ll notice everything is back to the earlier state.

Now try git add -A:

git add -A
git status

You’ll see that Git has staged everything again. So whether you use git add --all or git add -A, both do the same thing – Git stages every change. Next, run:

git reset
git status

Everything is unstaged again. Now, in this state, if you type this:

git add .

at first glance it seems like it’s doing the same thing as git add --all, as everything appears to be staged. But there’s an important difference. Reset again:

git reset

Now go inside the myFolder directory:

cd myFolder
git add .
git status

Git has only staged the three.txt file that’s inside myFolder. The other files in the root folder are still unstaged. This difference is really important:

• git add --all or git add -A stage every change across the entire project.

• git add . stages only the changes within the current directory (and its subdirectories).

Also, if there were a subfolder inside myFolder, using the dot would still include the files inside that subfolder too. In simple terms, the dot means “the current directory and everything inside it.”

So now you’ve seen three variations of the git add command: --all, -A, and . (dot). The first two work exactly the same way, while the dot version is limited to the current directory. Now run:

git reset
git status

to bring everything back again. Return to the root folder:

cd ..

And stage everything again:

git add --all

Now all files are ready to commit. At this point, imagine you make some changes directly in the working directory. For example, you delete the file two.txt and create a new one named four.txt, writing four inside it. That means you’ve deleted one file and added another new one.

Check the status:

git status

Git shows that under “Changes to be committed,” the previously staged files are still there. But under “Changes not staged for commit,” it now lists two.txt as deleted and four.txt as untracked. Now type:

git add *
git status

Git has staged the newly created four.txt file, but it hasn’t staged the deleted two.txt file. That’s why it’s important to understand that git add * only stages new or modified files, but not deleted ones. So to summarize:

• git add * stages visible new/modified files, but not deletions.

• git add . stages changes in the current directory, including modifications and deletions.

• git add -A / git add --all stage all changes (additions, modifications, deletions) across the entire repo.

Reset again:

git reset
git status

If you want to stage only a specific file – say one.txt, which has been modified – you can do that by typing:

git add one.txt

Similarly, if you want to stage a file inside a folder (for example the file inside myFolder) you can write:

git add myFolder/three.txt

You can also stage a single file like this:

git add two.txt
git status

You’ll see that only two.txt has been staged. You can also stage files by their extension. For example, to stage all .txt files:

git reset
git add *.txt
git status

This command stages all .txt files in the current directory, excluding deleted ones and excluding files inside subfolders.

Finally, if you want to stage everything at once, a simple and common practice is to go to the root directory and type:

git add .
git status

All the changes are now staged together. That means all your changes have been moved from the working directory to the staging area.

How to Save Work Permanently with git commit (and Configure Git)

So far, you’ve learned how to move changes from the working directory to the staging area using the git add command. Now let’s see how to save those changes from the staging area to the local repository. In Git’s language, this is called a commit. It means you’re confirming and saving your changes permanently.

You can think of it like getting ready for a party. You don’t just walk straight out the door. First, you stand in front of a mirror and check your clothes, shoes, accessories, and hair. That’s the stage where you make adjustments – maybe you realize, “This shirt doesn’t look good,” or “Let me change these shoes.” That’s an intermediate step. You haven’t left for the party yet – you’re just making sure everything is in order. If something’s off, you can fix it right there. Once you’re satisfied and everything looks perfect, that’s when you finally leave for the party.

Git works in the same way. Instead of going straight from the working directory to the local repository, you first move your changes to the staging area. This is an intermediate step where you can review, adjust, or even remove changes before saving them permanently. You don’t commit directly from the working directory because the staging area gives you a chance to verify everything before finalizing. When you finally “commit,” it means you’re sure everything is correct – no more mistakes – and now the work can be saved permanently. That’s why this process is called a commit.

First, check your current state:

git status

It shows that the staging area contains some changes that are ready but not yet committed. To commit them, write this:

git commit -m "I have made some changes to files"

The -m flag lets you add a short message describing what you changed.

Sometimes an error may appear the first time you try to commit. When you install Git for the first time and attempt a commit, you might see a message like this:

*** Please tell me who you are

This is completely normal. It’s just Git’s way of asking for your identity before recording a commit. Git needs to know who is making the changes and from which email address. This information is attached to every commit in the project history, which later helps track who made which changes.

Fixing this issue is simple. Git tells you exactly what to do. Run the following two commands:

git config --global user.email "your@email.com"
git config --global user.name "your name"

By running these two commands, the problem is solved. The first command sets your email address, and the second sets your name. The --global flag means that this configuration will apply to your entire computer - so every Git commit you make from this machine will use the same name and email.

If you want to make the configuration specific to a single project, you can use the --local flag instead. That way, the settings will apply only to that particular repository.

In short, when you use Git for the first time, setting up your user configuration is mandatory. It’s part of the basic Git setup you need to do before committing. Once it’s configured, Git will automatically recognize your identity for all future commits. If Git is already configured, you don’t need to set it up again.

Now, let’s go back to the main task of making a commit:

git commit -m "I have made some changes to files"

Now the commit is done. The terminal shows how many files were changed, how many lines were added, and how many were deleted. You can verify everything by checking the status:

git status

Everything looks clean now, meaning all the changes have been successfully saved in the local repository. From now on, whenever you make new changes to any file, you’ll have to stage and commit them again, just like before.

One more thing about commits: you can always roll back to the previous state if needed. To do that, type the following:

git reset HEAD~
git status

This command will undo the last commit and bring everything back to the working directory. You’ll see that all the files have returned to the working directory, ready to be staged again. You can now modify or commit them as you wish.

This shows how much control Git gives you over your work. It’s just about remembering the right commands.

Before we move on to deleting and restoring files, go ahead and make a new commit again so you’re working from a clean state:

git add .
git commit -m "I have made some changes to files"

How to Delete and Restore Files with git rm and git reset

Now the commit is done. Manually delete the one.txt file from your file system and then go back to the terminal. Type:

git status

Git shows that one.txt has been deleted. If you then type:

git add .

the deletion will also be staged. Instead of deleting a file manually and then adding it again, you can perform both steps in a single command. If you want to delete a file and stage that deletion at the same time, type:

git rm four.txt

Here, four.txt is just an example. This command deletes four.txt and automatically moves that change to the staging area. Once you run this and check the status:

git status

you’ll notice that four.txt has been deleted and staged. You no longer have to perform two separate steps – deleting and adding manually. You can do both at once with this shortcut.

If you check in your file explorer, you’ll see that four.txt has disappeared. Now, roll back the deleted file using git reset. When you run a regular git reset, it only brings back the staged changes, not the deleted files. You’ll see the message “Unstaged changes after reset.” But if you check your file system, the deleted file hasn’t returned. That’s because a regular reset only brings back staging information, not the physical file. You can confirm this with:

git status

You’ll notice only the changes are back, and that manually deleted files are still missing. If you want to restore everything (both the changes and the deleted files) you have to run:

git reset --hard

Once you execute this, both your changes and the deleted files return to their previous state.

Now let’s explore the use of git rm a bit deeper. Suppose you want to remove a file. First, reset everything:

git reset --hard

Now you’re back to your original state. Edit the four.txt file and write 4 inside it. That means there’s now a modification in the working directory. If you try to delete it directly using:

git rm four.txt

the file isn’t deleted, and Git shows an error: “the following file has local modifications.” This means Git isn’t allowing the deletion because it has detected uncommitted changes in that file.

Before you can remove it, you either have to commit those changes or confirm that you truly want to discard them. If you’re sure you want to delete the file anyway, you can force it by using:

git rm -f four.txt

As soon as you run this command, the file is forcefully deleted. If you check your file explorer, you’ll see that four.txt is gone. Now consider another situation. Run another hard reset:

git reset --hard

This brings everything back again. Modify four.txt by writing hello inside it. Now, if you type:

git rm --cached four.txt

this removes the file from the staging area but keeps it physically in your working directory. Check it:

git status

You’ll see that four.txt has moved to the “Untracked files” section: it’s no longer staged, but the file itself still exists in the system. That’s the difference between the --force and --cached flags:

• git rm -f completely deletes the file.

• git rm --cached removes the file from staging (and from tracking), but keeps it in your working directory.

Another useful command is:

git rm -r folder

Here, the -r flag stands for “recursive.” This means if the folder contains other subfolders or files, all of them will be removed recursively. If you mention the folder name without -r, then only that folder will be removed, not its contents. Try this out. Reset everything again:

git reset --hard

Now experiment with myFolder:

git rm -r myFolder
git status

The folder is deleted from your file system as well, and myFolder is listed as deleted and staged automatically. Reset everything again:

git reset --hard

How to View Commit History with git log

So far, you’ve made quite a few commits. Now you’ll learn how to view those commits. Viewing commits means checking the commit log. In the terminal, type:

git log

You’ll see the full commit history. You might see three commits, for example. Along with each one, there are details and messages that clearly describe what was done in that commit.

You’ll also notice long random strings which are commit IDs. Using these IDs, you can go back to previous versions later on. The first two commits might be the ones created when you made files while setting up your GitHub repository, and the last one might be when you modified some files recently.

If you want to view this log in a cleaner, more compact format, you can use:

git log --oneline

Once you run it, you’ll see a short summary of each commit with just the essential information. The commit IDs are also shown in a shortened format. These shortened IDs can also be used to return to any previous version later on.

Branching and Merging in Git

Now let’s move on to one of Git’s most powerful and important features: branching. At the moment, your repository has only one branch. A branch in Git is like a separate line of development where you can work independently.

If you check the online repository you cloned earlier, you’ll see that the default branch is called main. This is the default branch where all work begins. In recent times, Git has shifted from calling it “master” to “main,” but the idea remains the same: the main branch is your project’s central line of development.

To understand branching more simply, imagine you’re working in the kitchen of a large restaurant. The main branch is the main kitchen where all the dishes are prepared and served to customers. Now, if your client wants to try a new dish or recipe, you wouldn’t experiment directly in that main kitchen, because if something goes wrong, it could ruin everything.

Instead, you create a separate test kitchen where you can safely prepare and test the new dish. Once the recipe is perfected, you bring it back into the main kitchen to serve it officially.

Git works exactly the same way. Instead of making changes directly in the main branch, you create a separate development branch where you test and commit all your changes. Once everything is stable and verified, you merge that branch back into the main branch. This ensures that your main project stays safe, while new features can be developed and tested without breaking anything.

In short, branching in Git provides a secure and organized intermediate step that allows you to review, test, and manage changes before merging them into the main codebase.

Since I’ve already mentioned the word “merge”, let’s understand what it means. Merging simply means combining the changes from two branches into one. It’s an important concept for understanding how branches work.

In Git, you can create multiple branches – like staging, development, frontend, or backend – and work on each of them separately. Once all the changes are finalized and tested, they’re merged back into the main branch.

Right now, your application has only one branch. To see how many branches you have, type:

git branch

This command shows the list of all branches. At the moment, you may have only one, and the branch you’re currently in has a star (*) next to it.

To create a new branch, type git branch followed by the branch name. For example:

git branch development
git branch

You’ll see two branches listed: main and development. The star next to main means you’re still on the main branch. You can easily switch from one branch to another.

When a new branch is created, it takes the exact state of the branch you were on at that moment. So, in this case, the development branch is an exact copy of the main branch. Whenever you create a new branch, it inherits the current state of the branch you’re in.

Now that you’ve created a new branch, switch to it:

git checkout development
git status

You’re now inside the development branch. If you check the status, everything looks clean, because the development branch was created with the same content as main. Go to your file system and create a new file named three.txt. Inside it, write three. Then, back in the terminal:

git status
git add .
git commit -m "I created three.txt and entered three there"

Now your commit is done inside the development branch. Next, switch back to the main branch:

git checkout main

When you check your file system now, you’ll notice that three.txt is no longer there. Why? Because the changes made in the development branch exist only in that branch. Those changes haven’t been merged into main yet. The moment you switch back to main, Git automatically hides the changes made in development, showing you only what exists in the main branch.

This demonstrates how much control Git has over your file system. When you switch branches, Git instantly adjusts which files are visible so that you only see the changes relevant to that specific branch. There’s no duplication or conflict in your file system, as Git manages everything seamlessly.

In this way, you can create hundreds of branches, each containing its own set of changes, and Git will always show you a separate, isolated view for each one.

For any change to take effect, you must commit it. Whatever branch you’re working in, the commit must be made there. Once committed, Git understands that those changes belong exclusively to that specific branch. That’s why, when you switch back to the main branch, the changes made in the development branch don’t appear there.

Now suppose you make a new change to the four.txt file while you’re on the main branch – you add a 4 to it. Then, if you check the status:

git status
git add .
git commit -m "I changed four.txt and added additional 4"

Now, both branches have changes – the main branch has this new commit, and the development branch still has its previous one. Since both branches now contain updates, you’ll need to merge the changes.

First, switch to the development branch:

git checkout development

Now run:

git merge main -m "merging main into development"

After the merge, the changes made in the main branch appear inside the development branch as well. For example, the updated four.txt file is now present in the development branch alongside the previous changes. Both branches’ updates have been combined, and the development branch now reflects all the latest modifications.

Next, switch back to the main branch:

git checkout main

The changes from the development branch haven’t yet appeared here. From main, merge everything from development:

git merge development -m "merging on main with development"

After running this command, you’ll see that the three.txt file from the development branch now appears in main as well. Both branches’ changes have been successfully merged, and the merge process is complete.

Understanding Merge Conflicts

Sometimes during a merge, conflicts may occur. A merge conflict happens when the same part of a file has been changed differently in two branches.

For example, if you modified one.txt in the main branch and someone else modified the exact same section of one.txt in the development branch, Git won’t know which version to keep.

In such cases, Git flags the file as having a conflict, and you have to resolve it manually by deciding which changes to keep – or by merging both versions yourself.

Right now, you’re on the main branch. From here, you’ll create a new branch so that main remains untouched while you simulate a conflict. Run:

git branch staging
git checkout staging

This creates a new branch named staging, which contains all the latest updates from main, and switches you to it. While working on the staging branch, go to four.txt. At the end of this file, there was the number 4. Add 44 at the end and save the file. Now the staging branch has a change.

Run the following:

git status
git add .
git commit -m "changed 44"

The staging branch work is done. Next, switch back to the development branch:

git checkout development

When you open four.txt here, you don’t see the 44 you added earlier in staging. So, write 444 and save the file. Then run:

git add .
git commit -m "added 444 on four.txt"

The development branch now has its own separate change. While staying in the development branch, try to merge the changes from the staging branch:

git merge staging

Git fails to merge automatically and shows an error:

Automatic merge failed; fix conflicts and then commit the result.

This happens because the same line in four.txt was modified in both branches, staging and development. Git can’t decide which version should take priority, so it leaves the decision to you.

In this case, the developer working on the development branch (or whoever is managing it) has to manually resolve the conflict. When you open four.txt in a text editor, Git marks the conflicting section clearly, showing which part came from staging and which part came from development. You’ll see both the 44 from staging and the 444 from development. It’s now up to you to decide whether to keep one, remove one, or combine both changes.

While staying on the development branch, you decide which version to keep – for example, 444. You’ll then need to remove all the conflict markers, save the file, and then run:

git add .
git commit -m "merge conflict solved"

Now switch back to the staging branch:

git checkout staging

When you open the file system and check four.txt, it still shows 44, meaning no change has been applied yet. At this point, you can choose to merge changes either into staging or development since both branches are now in sync in terms of expected final content.

From staging, run:

git merge development

This time, Git merges everything smoothly without any conflict because both sides now contain compatible content. When you check the status:

git status

it shows everything is clean. Now, if you want to bring these merged changes into the main branch, switch to it:

git checkout main

Once you’re on the main branch and open the file system, you may notice that four.txt doesn’t yet have the latest update. Merge the staging branch:

git merge staging

All the latest changes flow into the main branch. The updates from both branches now combine into the final version. That’s how the entire process of merging and resolving merge conflicts works. You’ve now seen how branching works and how to switch from one branch to another using git checkout. Let’s dig a bit deeper into that command.

How to Navigate History with git checkout and Compare Commits with git diff

Earlier, when we talked about git log, I mentioned that you can go back to a previous version using a commit ID. That’s what you’ll see now – and to do that, you’ll again use git checkout.

First, check your commit history:

git log --oneline

Suppose you have nine commits in your log. Make a small change. Open one.txt and write hello inside it. Then stage and commit:

git add .
git commit -m "update one.txt file"

Next, run:

git log --oneline

All the commits are displayed. Now let’s say you want to switch back to one of your previous commits, specifically the one named “merging main into development.” To do that, copy the commit ID of that commit and type:

git checkout <that-commit-id>

Earlier, when you switched branches, you used the branch name. This time, you’re using a commit ID instead. Remember, your commit ID will be different.

After running this command, the project moves from the main branch to the exact state it was in at that previous commit. You must ensure that all your changes on main are tracked and committed before doing this. If there are any untracked or uncommitted files, Git won’t allow you to checkout to a previous version.

Once you run the command, you’ll see that in the terminal, instead of showing main, it now says something like:

HEAD detached at <commit-id>

That means you’ve successfully switched to that particular commit. If you open one.txt now, you’ll notice that the hello line you added earlier is no longer there. This confirms that you’ve returned to the previous version of your project.

If you want to go back to your latest state – meaning returning to the main branch – use:

git checkout main

You’ve switched back to the main branch, and you’re back to the most recent version of your project.

So now you’ve seen how to switch between commits and move from one version to another. Now we’ll explore how to compare one commit with another.

If you want to see the differences between your current commit and a previous commit (that is, what lines of code were added, what lines were deleted), you can do that easily using Git commands.

First, check your commit history again:

git log --oneline

Suppose there are now 10 commits in total. You’ll compare the commit “update one.txt file” with the previous one “merging main into development.” For that, you’ll need the commit IDs of both.

Since you’ve already run git log, copy those two IDs. Once you have them, write the command:

git diff <first-commit-id> <second-commit-id>

After running this command, Git shows the exact changes made between those two commits. The terminal displays which files were changed, what was removed (usually in red), and what was added (usually in green).

One important detail: in git diff, when you place the most recent commit ID first and the older one second, Git shows differences from the perspective of the newer commit – that is, what’s newly added or removed compared to the older one. If you reverse the order (older commit ID first and newer second), Git shows the opposite perspective. Try running the command both ways a few times and you’ll easily understand how the comparison works.

If you’re ever inside an interactive log or diff view, you can exit by pressing q on your keyboard. That closes the view immediately.

How to Work with Remotes: git push, git fetch, and git pull

So far, everything you’ve done has been inside your local repository – staging files, making commits, and storing everything locally. But the real goal is to send those updates to the remote repository, like GitHub.

When you send local changes to a remote repository, that process is called a push. If any changes have been made in the remote repository that you want to bring into your local repository, you can use fetch.

When you run git fetch, the remote changes are downloaded into your local repository’s memory, but they won’t appear in your working directory yet. To update your working directory and see those changes in your files, you need to run git pull.

In short:

• push sends local changes to the remote.

• fetch brings remote changes into your local repository (but does not merge them into your working directory).

• pull fetches and merges; it updates your working directory immediately.

In other words:

git pull = git fetch + git merge

Example: git push

You’ve already made several changes in your local repository, and now you want to push them to the remote main branch. Since you’re currently on the main branch, use:

git push origin main

Here, origin refers to the remote repository, and main is the branch you want to push to. After running this command, all your latest commits are sent to the remote main branch. If you check your repository on GitHub, you’ll see that everything is updated. But only the main branch is pushed – other branches aren’t uploaded yet. This means you’ve only pushed your main branch to the remote’s main.

Example: Pushing Other Branches

Switch to the staging branch:

git checkout staging
git push origin staging

Git creates a new branch named staging in the remote repository and pushes all your staging changes there. When you check GitHub again, you’ll see that the staging branch has been created and updated.

Similarly, switch to the development branch:

git checkout development
git push origin development

The development branch is also uploaded to the remote. Now all three branches (main, staging, and development) are fully synced with the remote repository.

Finally, switch back to the main branch again:

git checkout main

Example: git fetch

Imagine you’ve already pushed your local changes to the remote. Now let’s see how git fetch works.

Suppose you make a change directly on GitHub. For example, open the file three.txt on GitHub, type 3, and commit the change. Now, the remote main branch has a new update that your local main branch doesn’t have – it’s behind the remote version. While staying on the local main branch, bring in the latest changes from the remote:

git fetch

Git fetches the new changes from the remote repository, but those updates don’t yet appear in your local file system. For example, you won’t see the update in three.txt until you merge the fetched changes. Once you run:

git merge

the remote changes are integrated into your local working directory as well.

Example: git pull

Now, suppose you edit the remote three.txt file again, this time adding 33 after 3 and committing it on GitHub. The remote main branch is now ahead again.

To bring in all those updates and merge them into your local main branch at once, use:

git pull

git pull automatically performs both fetch and merge in a single command, meaning all the new remote changes, including the latest updates in three.txt, immediately appear in your local files.

You’ve now learned how to:

• push changes from local to remote (git push),

• fetch changes from remote without merging (git fetch), and

• pull changes from remote while merging them automatically (git pull).

These three commands are among the most frequently used Git operations and are more than enough for most daily development work.

How to Undo Local Changes with git restore

Now imagine you’re working on a project. You start developing a new feature, write a lot of new code, and modify several existing files. After some point, you realize that the approach you took isn’t working at all. But by then, you’ve already made changes across 10 to 15 different files – some with new code, some heavily modified.

In this situation, you want to discard everything and go back to the previous state. Would you really open each of those 10 to 15 files manually, remove all the new lines, and try to restore the old code one by one? How accurate or even possible would that be? Probably not at all.

In this case, the simplest answer is that it’s actually not practical manually. And the more complicated answer is that there’s no guarantee that everything will return to its exact previous state. This is exactly where the magic of the git restore command comes in.

The git restore command helps you revert any file or directory back to its previous state, meaning the state of the last commit. It’s mainly used to undo local uncommitted changes, or to remove changes that were added to the staging area using git add. Let’s test it. Suppose in one.txt, you write:

new feature

This repository already had some committed history. Now you’re just trying to develop a new feature. After writing the new code, you realize that the change you made in one.txt (adding new feature) was a mistake. The previous version was fine.

Since this change isn’t ready to be committed, you want to undo it and go back to the last committed state. To do that, run:

git restore one.txt

As soon as you run this command, the file instantly reverts to its previous state – the exact version from the most recent commit.

If you want to restore an entire directory instead of a single file, type the directory name after git restore and it’ll bring everything in that folder back to the last committed version.

If you want to undo all changes across the entire repository, run:

git restore .

This restores every file to its last committed state. If you’ve already staged some changes using git add, you can still undo them using the --staged flag. For example:

git restore --staged fileName
# or
git restore --staged .

This removes the files from the staging area but keeps the working directory unchanged.

In summary, the git restore command helps you bring any file or directory back to its previous (last committed) state. It’s mainly used to undo local, uncommitted changes before they’re ever committed.

How to Temporarily Shelve Work with git stash

Now imagine this: you’re working on a new branch, developing a big feature. It’s a long process, and you’ve already finished about half of it. But the work isn’t yet in a state to be committed.

Suddenly, another developer messages you saying there’s a new update on a different branch and you need to check it and give feedback. How will you switch branches without losing your unfinished work? Will you throw away all your progress using the git restore command?

Of course not. There’s no reason to go through that kind of hassle when Git gives you a much smarter way to handle this: using the git stash command.

With git stash, you can temporarily set aside your unfinished work, switch to another branch to do something else, and later bring all your changes back with a single command.

Let’s see how it works. Suppose in one.txt, you write:

another feature

You’re currently on the main branch. Now you need to switch to the development branch to review a new feature. So you type:

git checkout development

But Git throws an error:

error: Your local changes to the following files would be overwritten by checkout:
    one.txt
Please commit your changes or stash them before you switch branches.
Aborting

This happens because Git doesn’t allow switching branches when there are uncommitted changes – it’s protecting your work. But since your feature isn’t ready to be committed, this is exactly when you use git stash. Run:

git stash

The moment you execute this command, your uncommitted changes disappear from your working directory – but they’re not lost. Git has safely stored them in a temporary area called the stash. This lets you switch branches freely without affecting your unfinished work. Now, switch to the development branch:

git checkout development

You’ve now successfully switched branches. You can review the new feature, make notes, and do whatever you need to. Once you’re done, switch back to your main branch again:

git checkout main

Now, when you look around, you’ll see that your unfinished feature – the one you were working on earlier – isn’t there. It’s still saved in the stash. To bring it back, “pop” it out of the stash:

git stash pop

As soon as you run this, all your stashed changes reappear in your working directory. The pop command restores the most recently stashed work and simultaneously removes it from the stash list. If you’ve stashed multiple times, Git keeps them all in order – newest on top, oldest at the bottom. When you pop, it brings back the most recent one first.

If you want to reapply the stashed changes without removing them from the stash list (so that you can reuse them later), use the apply command instead:

git stash apply

Your changes are restored, but they also remain safely stored in the stash for future use. You can stash again:

git stash
git stash apply

You’ll notice it behaves almost the same as before, and the changes come back just like when you used pop. You already know that Git can store multiple stashes, and you can view a list of all those stashed changes. To see that list, type:

git stash list

You’ll see a list of all your saved stashes. Each stash item is marked with an identifier like stash@{0}, stash@{1}, and so on. You can use these identifiers to apply or pop specific stashes:

git stash pop stash@{0}
# or
git stash apply stash@{0}

Both commands work. The only difference is how they handle the stash afterward. To understand the difference more clearly, suppose you check your stash list:

git stash list

and see just one stash. If you previously used git stash apply, that stash item is still there. To remove a stash manually, use git stash drop. The drop command removes a specific stash from the stash list. For example:

git stash drop
git stash list

Now the stash list is empty. Since you used git stash apply earlier, all the changes are still in your working directory. Confirm that with:

git status

The changes you applied are still there. Now stash those changes again:

git stash
git stash list

You’ll see one stash entry again.

Then run:

git stash pop
git stash list

The stashed changes are restored into your working directory, and the stash list is now empty. pop brings your changes back and removes them from the stash list – it’s like taking them out permanently. Stash something again:

git stash
git stash list

Now run:

git stash apply
git stash list

The command works. Your files are restored, just like before. But the stash is still in the list. So here’s the key difference:

• git stash pop restores your changes and removes them from the stash list.

• git stash apply restores your changes but keeps them in the stash list for future use.

How to Undo Commits Safely with git revert

Now let’s talk about git revert. The git revert command is used to undo the changes made in a previous commit – but instead of deleting that old commit, it creates a new one that reverses those changes. In other words, it cancels out the effects of a previous commit while keeping the project history completely clean and traceable.

That’s why it’s called “revert”: because it doesn’t delete any commit. Instead, it creates a new commit that brings the project back to its previous correct state. Simply put, git revert means fixing an old mistake without erasing it.

For example, imagine you accidentally added too much salt while cooking. Instead of throwing the whole dish away, you adjust the flavor by adding some extra ingredients to balance the saltiness. Similarly, git revert doesn’t delete the faulty commit – it corrects it through a new one.

To revert something, you need its commit ID. Suppose in the file three.txt, you added the line:

hello three

Then you run:

git add .
git commit -m "hello three"

Now, if you check the log:

git log --oneline

you’ll see there are 10 commits in total. You realize that the "hello three" commit introduced a bug and you want to remove it. Before that, copy the commit ID of "hello three" and then run:

git revert <that-commit-id>

After running the command, you’ll see a prompt asking for a commit message. You can type a custom message or simply keep the default one and exit (for example, by using - wq in Vim). Once you do that, the changes from "hello three" will be undone. Check the logs again:

git log --oneline

You’ll notice there’s a new commit added specifically for the revert. At this point, you might be reminded of git reset. The main difference between git reset and git revert is:

• git reset can take you back to a specific commit and discard all commits after that point, without creating any new commit.

• git revert removes the changes from a specific commit by creating a new commit that reverses it.

If your project is on GitHub or any remote repository, other contributors can also see the revert commit, ensuring clarity and preventing confusion.

Another key point is that if you check the logs after a reset, there’s no record of the removed commits. But when you use revert, you’ll clearly see an additional commit indicating that a revert took place.

How to Keep History Clean with git rebase

Now let’s talk about Git Rebase. Imagine you’re starting to work on a new feature. You create a new branch called feature by checking out from the main branch. You begin developing the new feature, making changes bit by bit, and committing your progress as you go. Meanwhile, another developer adds more updates to the main branch for production. Now you want to include those latest updates from main into your feature branch. What can you do?

There are several ways to handle this. As we’ve seen before, one option is to merge the main branch into your feature branch. If you do that, Git creates a new merge commit, and all the latest updates from main are merged into your feature branch.

But merging always creates an additional commit – you can see it clearly if you run git log. Some developers find these extra merge commits a bit messy. If you continue merging multiple times, your commit history can look cluttered.

In such cases, a better solution is to use Git Rebase. When you perform a rebase, the base of your feature branch changes. That means if you rebase onto main, all the new commits from main are applied directly into your feature branch, and then your feature branch commits are reapplied on top of them. While your main branch’s code content remains the same, the commit history becomes much cleaner and more linear – and you can easily verify this using git log.

Let’s understand this with an example. Create a new branch called feature from main:

git branch feature
git checkout feature

You’re now inside the feature branch. Open one.txt and add the line:

adding dark mode functionality

Then stage and commit:

git add .
git commit -m "adding dark mode functionality"

Now switch back to the main branch:

git checkout main

You’re now in the main branch. Create a new file called two.txt and write:

adding dark mode ui

Then stage and commit:

git add .
git commit -m "adding dark mode ui"

Now the main branch has a new feature – “dark mode ui”. You want that same “dark mode ui” update to appear in your feature branch as well. Switch back to your feature branch:

git checkout feature

Your goal is to bring the latest updates from the main branch into the feature branch. But this time, we’ll do it using rebase.

To perform a Git rebase, you need to be on the branch you want to rebase, and then specify the branch from which you want to bring the changes. For example, if you’re currently on the feature branch and want to bring in the changes from main, run:

git rebase main

Once you run this command, the rebase completes, and the “dark mode ui” update from the main branch appears in your feature branch.

Here’s what happens behind the scenes when you use rebase:

1. Git identifies the most recent common commit shared between your current branch (feature) and the branch you’re rebasing onto (main).

2. All the commits in your feature branch that come after that common commit are temporarily set aside.

3. Git applies all the new commits from the main branch into your feature branch.

4. Finally, it reapplies the saved commits from the feature branch on top of those main commits, one by one.

The result is a clean, linear commit history that’s much tidier than what you get with merging. You can easily see this difference by running git log.

Just keep in mind that git rebase is powerful. So it’s not recommended to use it on public repositories or branches where multiple developers are working together. If you must use it, you should always inform your team beforehand. Otherwise, it can cause serious issues.

The reason is that rebase rewrites existing commit history – even the commit hashes (IDs) change. So, if someone else is working on the same branch, your rebased commits won’t match their local copies anymore, and they won’t be able to pull or sync normally.

So before using rebase, make sure you fully understand where you’re applying it and whether it could cause problems for your collaborators. It’s perfectly safe to use rebase on your local or personal branches where only you’re working – just avoid rewriting commits that already exist on a shared remote branch.

How to Collaborate on GitHub with Pull Requests

Before wrapping up, let’s discuss one last important topic: the Pull Request. When working with Git and GitHub, the term “Pull Request,” often shortened as “PR,” comes up frequently.

A Pull Request is essentially a request you make to merge your changes into another branch – usually the main branch. It’s a way of saying, “I’ve made some changes in my branch. Please review them, and if everything looks good, merge them into the main branch.”

In other words, you typically don’t make changes directly to someone else’s repository. When you finish your work in your own branch, you create a Pull Request to ask for permission to merge your code into the main repository. That’s what a Pull Request is.

Go back to your git-journey repository on GitHub. By now, you’ve already pushed your main, staging, and development branches. At the top of the GitHub page, you’ll see several tabs: Code, Issues, Pull requests, and Actions.

Click on the Pull requests tab. Here, you’ll see a big green button labeled New pull request. This is where you can say, “I want to merge the changes from this branch into another branch.”

Once you click New pull request, GitHub shows you two dropdown menus:

• base: the branch where you want to merge the changes (select main here).

• compare: the branch from which you want to bring the changes (select development).

In other words, you’re saying, “I’ve made some updates in the development branch, and now I want those updates to be merged into the main branch.” GitHub automatically shows a detailed comparison: which files have been modified, which lines have been added, and which ones have been removed, with everything clearly visible. If everything looks good, scroll down and click Create pull request.

Give your PR a title, such as:

Merge development updates into main

In the description box, you can write something like:

This PR adds the latest updates and fixes from development to main.

Then click Create pull request to submit it. Now, if you go back to the Pull requests tab, you’ll see your newly created PR:

development → main

Click on it, and you’ll find three sections:

• Conversation: where you and your teammates can discuss or comment on the changes.

• Commits: which lists all the commits included in this PR.

• Files changed: which shows exactly what changes were made in which files.

If everything looks good after review, click the green Merge pull request button at the top, and then confirm by clicking Confirm merge. Once it’s done, GitHub displays a message:

Pull request successfully merged and closed.

That means all the updates from the development branch have now been successfully merged into main.

This is how Pull Requests make code management much easier. Every change gets reviewed first and then merged into main. As a result, the main branch stays stable, and the entire team can collaborate safely and efficiently.

Git & GitHub – Concise Summary

Git vs GitHub

• Git: Local version control tool that tracks every change to your files, lets you keep multiple versions, and roll back any time.

• GitHub: Online hosting platform for Git repositories that acts like a central “code server” so teams can share, review, and collaborate.

• Other Git hosts exist (GitLab, Bitbucket), but GitHub is the most widely used, especially for open source.

Core Git Architecture & Workflow

• Work happens in the working directory (your project folder).

• When changes are ready, you move them to the staging area with git add.

• You permanently record a version in the local repository with git commit.

• The remote repository (for example, on GitHub) is a copy of your repo stored in the cloud for backup and collaboration.

Basic flow:

1. Edit files in the working directory.

2. Stage changes: git add <files> or git add .

3. Commit: git commit -m "message"

4. Sync with remote: git push / git pull

Getting Started

• Install Git from the official site: https://git-scm.com/downloads.

• Check installation: git --version.

• Configure identity (needed before first commit):

  • git config --global user.name "Your Name"

  • git config --global user.email "you@example.com"

• Initialize a repo in a folder: git init.

• Or clone an existing repo from GitHub: git clone <repo-url>.

Seeing & Moving Changes

• Check what changed and what’s staged: git status.

• Stage changes:

  • git add --all / git add -A: stage everything (adds, changes, deletions).

  • git add .: stage changes only in the current directory.

  • git add <file> or git add *.txt: stage specific files or patterns.

• Unstage everything (but keep edits in files): git reset.

• Save staged changes as a commit: git commit -m "message".

• View commit history:

  • Full: git log

  • Compact: git log --oneline

Deleting, Restoring, & Undoing

• Delete a tracked file and stage the deletion: git rm <file>.

  • Force delete changed file: git rm -f <file>.

  • Stop tracking but keep file: git rm --cached <file>.

• Undo staged changes only: git reset.

• Reset everything (including working directory) to last commit: git reset --hard.

• Restore file content back to last commit:

  • Single file: git restore <file>

  • All files: git restore .

• Undo a commit safely (create a new “fix” commit):

  • git revert <commit-id>

• Move HEAD and history back to an earlier commit (dangerous on shared branches):

  • Example: git reset HEAD~ (undo last commit locally).

Branching, Merging, & Conflicts

• A branch is an independent line of development (for example, main, development, staging, feature).

• List branches: git branch.

• Create branch: git branch development.

• Switch branch: git checkout development (or git switch development in newer Git).

• Typical workflow: keep main stable, build new features on separate branches, then merge back.

• Merge another branch into the current one: git merge <branch-name>.

• If the same lines changed differently in two branches, you get a merge conflict:

  • Git marks conflicts in the file with <<<<<<<, =======, >>>>>>>.

  • You manually edit to the correct final content, then:

    • git add .

    • git commit -m "merge conflict resolved"

Navigating & Comparing History

• Jump to an old commit (read-only “detached HEAD” state): git checkout <commit-id>

• Return to the latest main: git checkout main.

• Compare two commits: git diff <old-id> <new-id> – shows what changed between them.

Working with Remotes (GitHub)

• Push local branch to remote: git push origin <branch>.

• Fetch latest state from remote without updating your working files: git fetch

  • Then merge if needed: git merge origin/main

• Pull and merge in one step: git pull (equivalent to fetch + merge).

Temporarily Shelving Work with git stash

• Use git stash when you have uncommitted work but need to switch branches.

• git stash: saves current changes and cleans your working directory.

• Switch branches, do other work, then come back and restore:

  • git stash pop: restore and remove from stash list.

  • git stash apply: restore but keep entry in the stash.

• See all stashes: git stash list.

• Remove a stash explicitly: git stash drop.

Keeping History Clean with git rebase

• git rebase <branch> replays your current branch’s commits on top of another branch, creating a cleaner, linear history.

• Safe on your own local branches, but dangerous on shared/public branches because it rewrites commit history (IDs change).

• Common pattern: on feature branch, run git rebase main to bring latest main changes under your feature commits.

Collaboration with Pull Requests (PRs)

• On GitHub, you usually:

  1. Push your feature branch.

  2. Open a Pull Request (PR) to request merging into main (or another base branch).

  3. Teammates review code, discuss in comments, and approve.

  4. The PR is merged (and usually closed) once accepted.

• PRs keep main stable and make reviews and history clearer.

Big Picture Takeaways

• Git tracks every change, lets you move safely between versions, and protects you from losing work.

• GitHub (or other remotes) adds backup, sharing, and collaboration.

• Most day‑to‑day work is based on a small set of commands: git status, git add, git commit, git push, git pull, git branch, git checkout, git merge, git log.

• Advanced commands like git reset, git restore, git revert, git stash, and git rebase give you powerful ways to undo mistakes and keep history clean.

Final Words

This tutorial on Git and GitHub has walked through the essential, day-to-day concepts in a step-by-step, practical way. It’s especially helpful for those who are just getting started. If you’ve always felt a bit intimidated or confused about using Git for the first time, this guide was created with you in mind.

If you found the information here valuable, feel free to share it with others who might benefit from it. I’d really appreciate your thoughts – mention me on X @sumit_analyzen or on Facebook @sumit.analyzen, watch my coding tutorials, or simply connect with me on LinkedIn. You can also checkout my official website sumitsaha.me for more details about me.

We just posted a course that will help you learn Git and GitHub from scratch with clear examples, real workflows, branching, merging, stashing, rebase, pull requests, and more. This course is great for beginners who want strong foundations. Sumit Saha developed this course.

Here are the things you will learn in this video:

• The difference between Git and GitHub in the simplest way

• How Git tracks your work using the working directory, staging area, and repository

• Core Git commands: add, commit, status, log, reset, restore, rm

• How to work with branches, merge updates, and fix merge conflicts

• How to push, pull, and sync your code with GitHub

• Using stash, revert, and rebase to handle real-world workflows

• How pull requests work and why teams use them

Watch the full course on the freeCodeCamp.org YouTube channel (1-hour watch).

In this tutorial, you’ll to learn what the GitHub CLI is, how to install and set it up, and how to use it for everyday tasks such as creating repositories, managing issues and pull requests, working with GitHub Actions, and automating tasks using custom aliases. You’ll learn how to replace some functionalities on GitHub’s web interface with quick commands in your terminal.

Here’s what we’ll cover:

• Overview of GitHub CLI

• Key Features

• Benefits of Using GitHub CLI

• Installation and Setup

• Authenticating with a GitHub Account

• Navigating the GitHub CLI

• Managing Repositories

• Working with Pull Requests and Issues

• Pushing and Pulling Changes

• Working with GitHub Actions

• Managing Gists

• Releases and Tags

• Custom Scripts and Aliases

• Troubleshooting

• Conclusion

Overview of GitHub CLI

You can use the GitHub CLI to bridge the gap between GitHub's web interface and your local environment. You can perform various tasks such as creating issues, managing repositories, or even checking the status of your GitHub Actions workflows using the CLI. Using the CLI, you can perform almost all the tasks that you might complete on the GitHub website.

Key Features of GitHub CLI

• Repository management: Easily create, clone, view, and manage repositories.

• Pull requests and issues: Manage pull requests and issues directly from the terminal, including creating, merging, and listing them.

• GitHub Actions: Interact with workflows and manage workflow runs.

• Authentication: Provides a secure way to authenticate with your GitHub account, supporting SSH keys, tokens, and OAuth.

• Custom scripting: Lets you create custom scripts and aliases to automate repetitive tasks and streamline development processes.

Benefits of Using GitHub CLI

Suppose you’re working on a project, and you need to create a new issue on GitHub. Normally, you would switch to your browser, log in to GitHub, navigate to the repository, click on the “Issues” tab, and then click “New Issue.” With GitHub CLI, you can do all of this by typing a single command, without ever leaving your terminal. This makes your workflow faster and saves time.

Installation and Setup

To install GitHub CLI on Windows, you can use the winget package manager. Winget is a command-line tool that allows you to install software easily.

Installing GitHub CLI on Windows, macOS, and Linux

Windows:

Run the command given below:

winget install --id GitHub.cli

• winget install: Tells Windows to install a new software package.

• --id GitHub.cli: Specifies the exact package ID for GitHub CLI.

After running this command, GitHub CLI will be installed on your Windows system.

macOS:

You can use Homebrew to install GitHub CLI on macOS. Open your terminal and run:

brew install gh

Linux:

On Linux, you can use your package manager. For example, on Ubuntu, you can run:

sudo apt install gh

Authenticating with a GitHub Account

After installing GitHub CLI, the next step is to authenticate it with your GitHub account.

Run Authentication Command:

Type gh auth login in the terminal and press Enter.

gh auth login

You’ll then be prompted to select an authentication method. The recommended option is to authenticate via a web browser.

If you select the browser method, GitHub CLI will open a link in your default browser, where you can log in to GitHub.

Complete Authentication:

After logging in, the browser will confirm that the GitHub CLI is connected to your account.

You can verify the authentication status by running:

gh auth status

Navigating the GitHub CLI

The GitHub CLI is easy to navigate, and its command structure is intuitive.

Command Structure and Syntax

GitHub CLI commands follow a simple and straightforward pattern:

gh [command] [subcommand] [flags]

• Command: The main action you want to perform (for example, repo, issue, pr).

• Subcommand: A specific task within the command (for example, create, list, view).

• Flags: Optional parameters that modify the command's behavior (for example, --title, --body).

Commonly Used Commands and Flags

Here are some common GitHub CLI commands:

• Creating a repository: gh repo create

• Listing issues: gh issue list

• Creating a pull request: gh pr create

• Viewing a repository's details: gh repo view

To see all available commands and options, you can always run:

gh help

How to Manage Repositories with the GitHub CLI

Let’s go through examples of some of the commands you’ll use the most often.

Creating and Cloning Repositories

To create a new GitHub repository directly from the terminal, just use the following command:

gh repo create my-repo-name

To clone an existing repository, use the following command:

gh repo clone owner/repo-name

Managing Branches and Pull Requests

GitHub CLI allows you to handle issues and pull requests (PRs) without leaving the terminal.

Switching branches or creating pull requests is simple. To create a new branch:

git checkout -b new-branch-name

Then, to create a pull request:

gh pr create --title "Your PR Title" --body "Description of your PR"

Pushing and Pulling Changes

Push your changes to GitHub with this command:

git push origin branch-name

And pull the latest changes with:

git pull

Working with GitHub Actions

GitHub CLI also supports GitHub Actions, allowing you to manage workflows directly from your terminal.

You can manually trigger workflows using the following:

gh workflow run workflow-name

And you can monitor the status of workflows with:

gh run list

To see detailed logs of a workflow, run this:

gh run view run-id --log

Cloning and Forking Repositories

Cloning and forking are essential tasks when working on projects from other repositories.

To clone a repository, use this command:

gh repo clone <repository-name>

To fork a repository, do this:

gh repo fork <repository-url>

Example:

Here’s what it would look like:

gh repo clone example-repo

gh repo fork https://github.com/username/repository-name

How to Work with GitHub Actions

Using the GitHub CLI, you can also manage GitHub Actions, which are automated tasks you can run in response to certain events in your repository.

Triggering and Monitoring Workflows

You can trigger a workflow manually like this:

gh workflow run <workflow-name>

And you can monitor workflow runs with this:

gh run list

Managing Workflow Runs and Logs

If you want to check the details of a specific workflow run, you can view logs directly from the CLI:

gh run view <run-id> --log

You can also use GitHub CLI commands to enhance your Continuous Integration/Continuous Deployment (CI/CD) pipelines, ensuring smooth automation and better control over our workflows.

How to Update the GitHub CLI

To make sure that you’re using the latest version of GitHub CLI with all the latest features and fixes, you can update it using winget.

winget upgrade --id GitHub.cli

• winget upgrade: Checks for updates for the specified package.

• --id GitHub.cli: Identifies the GitHub CLI package for the upgrade.

Advanced GitHub CLI Features and Integrations

The GitHub CLI is not only useful for performing basic tasks. You can also perform some advanced operations with its help.

How to Manage Gists with the GitHub CLI

Gists are a simple way to share snippets of code. You can create, list, and manage your Gists right from the CLI. Here’s how you can create a gist:

gh gist create my-code-snippet.py

To list your gists:

gh gist list

Interacting with Releases and Tags

To manage releases and tags, GitHub CLI provides commands to create, list, and delete releases. Here’s an example of creating a release:

gh release create v1.0.0

How to Extend the GitHub CLI with Custom Scripts and Aliases

You can write your own scripts and integrate them into GitHub CLI, or create aliases for commands you use frequently to save time. Aliases let you create shortcuts for commands that you use often. For example, the command given below creates an alias prlist that will show all pull requests, regardless of their state:

gh alias set prlist "pr list --state all"

In the same manner, you can create a shortcut co to quickly check out a pull request branch without typing the full command each time. The command is given below:

gh alias set co "pr checkout"

Troubleshooting Common Issues

If you face any issues, you can troubleshoot by checking the command syntax, ensuring your GitHub CLI is up to date, or consulting the documentation using the command:

gh help <command>

Conclusion

GitHub CLI is an excellent tool that helps developers work directly from the terminal. It lets you manage repositories, handle pull requests and issues, trigger and monitor GitHub Actions, and even work with Gists.

You can save time and improve productivity as developers using this powerful tool. Keep exploring its new features and stay updated with the latest version.

Basically, the Lazygit tool is a wrapper for the Git command line that replaces it with a UI. Instead of typing out Git commands again and again in your terminal, you can use keyboard shortcuts to commit, push, pull, create, edit, and delete branches in your project.

In simple terms, Lazygit helps you increase your productivity while working with Git.

In this article, we'll walk through the essential features of Lazygit, and I’ll show you how it works.

Table of Contents:

1. How to Install Lazygit

2. How to Use Lazygit

3. Shortcuts and Key Mappings in Lazygit

4. Other Keybindings in Lazygit

5. Conclusion

How to Install Lazygit

Before we start, you’ll need to make sure it’s installed on your machine. You can install the tool in your system using the following methods (depending on your system):

Homebrew

You can install lazygit in macOS using Homebrew like this:

brew install lazygit

Scoop (Windows)

You can install lazygit in Windows using Scoop like this:

# Add the extras bucket
scoop bucket add extras

# Install lazygit
scoop install lazygit

Arch Linux

You can install lazygit in Arch using Pacman like this:

sudo pacman -S lazygit

Ubuntu and Debian

You can install lazygit in Ubuntu and Debian using the following command:

LAZYGIT_VERSION=$(curl -s "https://api.github.com/repos/jesseduffield/lazygit/releases/latest" | \grep -Po '"tag_name": *"v\K[^"]*')
curl -Lo lazygit.tar.gz "https://github.com/jesseduffield/lazygit/releases/download/v${LAZYGIT_VERSION}/lazygit_${LAZYGIT_VERSION}_Linux_x86_64.tar.gz"
tar xf lazygit.tar.gz lazygit
sudo install lazygit -D -t /usr/local/bin/

Verify the correct installation of lazygit:

lazygit --version

The command output looks like this:

➜  lazygit --version
commit=, build date=, build source=nix, version=0.44.1, os=linux, arch=amd64, git version=2.47.0

Fedora and RHEL

You can install lazygit in Fedora and RHEL using DNF like this:

sudo dnf copr enable atim/lazygit -y
sudo dnf install lazygit

NixOS

You can install lazygit in NixOS using the following method:

# with nix-shell
nix-shell -p lazygit

# with nix-env
nix-env -iA lazygit

# with /etc/nixos/configuration.nix
environment.systemPackages = [
  pkgs.lazygit
];
# or with enable lazygit flakes
nix run nixpkgs#lazygit

How to Use Lazygit

To use Lazygit, you don’t need any advanced knowledge about Lazygit or the Git CLI. If you are a beginner, that’s okay – I’ll walk you through the process and the basics here.

The main thing to understand is how the key mappings (shortcut keys) work. In this tutorial, I won’t discuss every key mapping, but I’ll teach you about some of the most common Lazygit key mappings which you’ll use on a daily basis. They’ll help you build a solid base for using the tool effectively.

To use Lazygit, first open the terminal you use. For example, I’m using the GNOME distro, so I’ll use the Ptyxis terminal.

Type the lazygit command in your terminal:

lazygit

The command output should look like this in your terminal:

The Lazygit UI is divided into six panels, or sections. Each panel serves a specific use case. Let’s explore these panels in more detail. You can see them highlighted in the image below:

Panels or Sections in Lazygit

As I mentioned above, there are six main panels in Lazygit. They are:

1. Status

2. Files

3. Branches

4. Commits

5. Stash

6. Previews

The most important panels in Lazygit are files, branches, and commits, but we’ll examine each of the six now.

Status panel

The status panel provides an overview of your current repository and the current checked-out branch, including local and remote changes.

Also, when you click on the status panel text, it opens a new tab or panel where it shows the recently opened repository list.

Files panel

The Files panel shows lists of the files in your repository that have been modified or changed. You can see files that you’ve deleted or discarded and unstaged.

Branches panel

The Branches panel shows lists of local and remote branches which are available in this repository.

Commits panel

The Commits panel shows a list of commits in the current branch, which allows you to view, checkout, or interact with (view/undo/and so on) specific commits.

Stashes panel

The Stashes panel helps you manage your stashed changes, allowing you to apply, drop, or view them. Git stash is a location for storing uncommitted changes (modified, staged, or untracked files) in a hidden place, letting you switch branches without committing or discarding them.

Preview panel

The preview panel lets you preview unstaged changes, commits, logs, file content, and so on in Lazygit.

To switch between panels, use the left and right arrow keys or the specific keybindings displayed at the top of each panel.

Press 1 to open the Status panel, 2 for Files, 3 for Branches, 4 for Commits, and 5 for the Stash panel.

Shortcuts and Key Mappings in Lazygit

Lazygit is especially popular because of its shortcuts. You don’t need to write the same Git commands in the terminal over and over. Rather, you just need to use a shortcut.

For example, usually when you commit a file, you’ll first add the file using git add and then commit the file using git commit.

But in Lazygit, you just have to select the file using your mouse or the up and down keys and press space to commit the file.

In Lazygit, everything works around the shortcut commands, and you use shortcuts to perform common Git operations. Here are a few essential commands we’ll go over in this tutorial:

• a – Stage or unstage all the files available in the Files panel.

• space (file panel) – Stage or unstage a single file in the Files panel.

• c – Commit staged changes by opening a commit message editor.

• p – Push commits to the remote repository.

• P – Pull changes from the remote repository.

• z – Undo the commit.

• s – Stash changes, allowing you to switch branches or perform other operations.

• S – View and apply stashed changes.

• n – Create a new branch.

• d – Delete your branch.

• y – Copy to clipboard.

• M – Merge branch.

• space (branches panel) – Check out the selected target branch.

• e – Edit or open the file in an external editor.

• q – Quit Lazygit and return to the terminal.

• d – Discard any changes in the file.

• ? – Open the keybinding menu.

Now let’s go over these shortcuts so you can understand how they work and see them in action.

How to Commit a File

To commit a file in Lazygit, first select the file you need by pressing the space key or the a key or double-clicking on the file. Then press c, and a new panel should open. There, you can add a message and hit enter to commit the file.

How to Pull and Push Code

To pull remote code from the Git server (Github, GitLab, Gitea, and so on), you can press p (lower case p):

To push local code into a Git server, you can press P (upper case P):

How to Create and Delete a Branch

To create a new branch in Lazygit, press n. A new panel will open where you’ll add the name of the branch and hit Enter.

To delete a branch, press d and then specify whether you want to delete the branch in a local or remote repository. In the following example, I’m deleting a local branch.

Note: To delete and create a new branch in Lazygit, first select the branch panel and then press the corresponding shortcut key for deleting a branch. Press the d key to delete, and then to create a branch press the n key. Otherwise, it won’t work.

How to Undo a Commit

To undo the last commit in Lazygit, just press z. A new panel will open, showing the details of the commit you are undoing. Then, hit Enter.

How to Merge a Branch

To merge a branch, press M (capital M). To open the merge options, choose the merge type, then hit Enter.

Merge type:

• Merge: A standard merge, preserving the branch history.

• Squash merge: Combines all commits from the branch into a single commit on the target branch.

• Squash merge and leave uncommitted: Same as squash merge, but leaves the changes uncommitted.

How to Resolve Merge Conflicts

To resolve merge conflicts in Lazygit, first merge a branch by pressing M, then choose the merge type (which I describe in the subsection on how to merge a branch) and hit Enter.

If any merge conflicts occur, the conflicting file(s) appear in the files panel. Press Enter to view the merge conflicts in the preview panel and navigate between conflicts using the up and down keys. Select the correct merge conflicts, press the space key, and your merge issue will be resolved.

How to Discard Changes

To discard or drop any changes in a file or commit, press d.

How to Copy

To copy a file name, path, commit hash, message, URL, author, or any other details, first select the commit or file, then press y to copy the information.

Other Keybindings in Lazygit

There are other keybindings in Lazygit which I did not discuss in this article. To learn about every keybinding, you can check out the keybindings menu. Open the keybindings menu and press the ?.

When you open the keybindings help menu, it changes according to the panel you’re in.

Conclusion

Lazygit helps you become more productive when working with Git or Git commands. As a beginner, starting with Lazygit can be somewhat challenging because of its key mappings, but once you get the hang of them, they’re pretty easy to remember and use.

If you are a first-time Lazygit user, my suggestion is to avoid using Lazygit on a working repository. Instead, create a demo repository and try it out/practice.

To learn more about LazyGit keybindings or shortcuts, you can refer to the Lazygit documentation. You can also check out the following YouTube tutorials for beginners:

• LazyGIt - A Faster, Easier Way to Use Git on Terminal & NeoVim

• Lazygit - The Best Way To Use Git On The Terminal & Neovim

• My new favorite way to use Git

• LazyGit: Effortless Git in Your Terminal!

The three concepts that stand out to me as the most fundamental for being able to effectively work with Git at a basic level are:

1. The working directory

2. The staging area

3. The commit history

In this article, we’ll take a new approach to representing these three concepts: by visualizing them in an immersive, 3D game world!

I’ll provide a tangible, visual representation of these key Git concepts which are almost always described in an abstract and confusing way. I hope that this will make them much more intuitive for you to grasp.

Table of Contents

1. Visualize your Working Directory

2. Demystify your Staging Area

3. Literally Walk through your Commit History

4. Summary

5. Try it Yourself

Visualize your Working Directory

What does your brain picture when you think of the “working directory”? I assume it’s something like a folder structure starting at the project root, containing the code files and subfolders that make up the project.

While that is a fair description of the working directory, it is a bit hard to imagine and misses the segmentation that Git applies to your project. Although the current state of your entire project, folder structure, and code files do reside in the working directory, Git doesn’t really need to do much about that unless certain changes are detected in those files.

Git detects and reports changes to the working directory with the Git status command, which shows output like this:

Jack@RAPTOR ~/my-project (main)> git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   main.py
        modified:   settings.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        one.py
        three.py
        two.py

no changes added to commit (use "git add" and/or "git commit -a")

The two relevant sections here are:

1. Changes not staged for commit: Lists existing files tracked by Git which currently contain code changes. In the example above, we see two “modified files”: main.py and settings.py.

2. Untracked files: Lists new files in your project that Git doesn’t know about yet. In the example above, we see three new, untracked files: one.py, two.py, and three.py.

When it comes to understanding Git, thinking of the working directory as the changes Git sees in these two sections – Untracked files and Modified files – is quite helpful.

But the git status command reports these details in the terminal in a purely text-based way, which doesn’t do newer Git users any favors when it comes to wrapping their heads around Git.

Some Git GUI’s do a better job with this (they do provide a safer point-and-click interface, after all), but in my experience, none of them make things obvious at a glance.

Instead, imagine that as a new Git user, you saw this:

A nice big wall with clearly delineated sections for Untracked files and Modified files. Files corresponding to each section are represented as blocks on the wall within that section, clearly labelled with their filename.

More specifically, the blocks representing files one.py, two.py, and three.py are all sitting neatly in the Untracked files section, and the blocks representing the files main.py and settings.py are in the Modified files section.

This makes it abundantly clear to even a total novice that Git is interpreting these files differently and categorizing them in a logical way. It takes the abstract Git concept of the “working directory” and transforms it into a form that almost anyone can wrap their heads around at a glance.

But something is missing here. Let’s say you run the command git add one.py. This stages the untracked file one.py to be included in the next commit. What happens to the block labelled one.py on the wall?

Demystify your Staging Area

To answer that, let’s move on to the mysterious Git “staging area”. But first, where exactly IS the staging area?

Well, technically any staged file changes are still just sitting in the working directory, which makes things a bit confusing.

Here is how Git reports this in the terminal:

Jack@RAPTOR ~/D/git-worlds (main)> git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   one.py

As you can see from Git’s output, it now includes the section Changes to be committed, which includes the file one.py that was staged with the git add command.

But this is still a bit unclear. Are the staged file changes in one.py still a part of the working directory? Or does Git store them elsewhere?

Well, the answer is… BOTH:

Here you can see that we zoomed out a bit from the previous image, to reveal a third section of the wall labeled Staged files.

Since we ran the command git add one.py, you can see that the corresponding block representing the one.py file moved from the Untracked files column to the Staged files column.

This conveys quite clearly that a file sitting in the staging area is still a part of the working directory (because it is a part of the overall wall), while also being segmented into its own designated space.

From a technical perspective, Git’s staging area is just a file named index which lives in the .git/ folder. Git builds up the code changes specified by the git add command in this file, which is used as the source for those changes the next time the git commit command is run.

But from a workflow perspective, representing the staging area as a section on the “working directory wall” as in the image above makes things more intuitive to understand.

Next, let’s explore how we might visualize things once the staged changes are turned into a new Git commit and become a part of the active branch.

Literally Walk through your Commit History

What does your mind’s eye see when you think of Git’s “commit history”?

Well, the prettiest way Git does it in the terminal is by using the Git log command, such as git log --graph --all, which provides output like:

* commit 88085cff3e2d7657f26eb6479b308526df7d2bba (HEAD -> dev, origin/dev)
| Author: Jacob Stopak <jacob@initialcommit.io>
| Date:   Tue Apr 23 20:31:24 2024 -0700
|
|     Fix command as title clip, ellipses and arrow length in rebase subcommand
|
|     Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
|
*   commit e264605ea26a808c34d4dc2fbc6dad65a8e28c5f
|\  Merge: cb3fa5f b8c071c
| | Author: Jacob Stopak <jacob@initialcommit.io>
| | Date:   Wed Mar 20 19:51:06 2024 -0700
| |
| |     Merge branch 'main' into dev
| |
* | commit cb3fa5f3bdbdcff3d9a8c844cda99d46bf64e337
| | Author: Jacob Stopak <jacob@initialcommit.io>
| | Date:   Sat Mar 9 22:00:49 2024 -0800
| |
| |     Add --staged flag to git restore subcommand
| |
| |     Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
| |
| * commit b8c071cb9a1653748525aa01c2b6bafe06ed9100
|/  Author: Jacob Stopak <jacob@initialcommit.io>
|   Date:   Wed Mar 20 19:50:53 2024 -0700
|
|       Correct license specified in pyproject.toml from MIT to GNU GPLv2
|
|       Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
|
* commit 32a3a3fca583f6c68225b974716e74b557a1a094
| Author: Jacob Stopak <49353917+initialcommit-io@users.noreply.github.com>
| Date:   Tue Aug 22 11:31:38 2023 -0700
|
|     Update README.md

Unfortunately, this is not so pretty at all. This long, garbled list of commit IDs, names, dates, and commit messages is definitely not something most folks would consider user-friendly.

The --graph option supplied above does show the commit relationships by drawing little lines connecting each commit in the terminal, but the purely text-based nature of this is just not intuitive to most people at a glance.

Now consider the following gamified representation of Git’s commit history:

Now we’re talkin’! In this image, each Git commit is represented by a white block with a shortened 6-character commit ID.

Each white commit block points back to its parent commit with an arrow, forming very clear chains of commits that make up Git branches.

You might have noticed that some of the white commit blocks have colored blocks sitting on top of them. The green blocks are branch names, the yellow blocks are Git tags, the blue block is Git’s HEAD pointer, and the red blocks are remote-tracking branches. These are collectively referred to as Git refs.

Besides being able to easily distinguish between them, representing ref types as different colored blocks clarifies another often-confusing Git concept. In Git, branches (along with other refs types) are just “pointers” to a specific commit. It is tempting to think of a branch as a series of connected commits that share a history – and conceptually this is correct – but in Git, a branch is really just a glorified label pointing to a specific commit.

In this gamified world, you can literally walk through your commit history to see, interact with, and examine the code changes in any commit.

Summary

In this article, we explored how Git’s fundamental concepts - the working directory, staging area, and commit history - can be difficult to grasp due to their abstract nature.

To make these concepts more accessible, we introduced a gamified, visual approach that transforms them into something tangible: an immersive game world where files and commits are represented as interactive blocks.

By presenting Git this way, beginner coders, students, and developers of all experience levels can intuitively learn Git concepts and commands, and confidently apply them in professional projects.

Try it Yourself

The images in this post were captured in Devlands, the first and only gamified Git interface and tutorial, which I’m building in Python.

In Devlands, not only can you walk through your codebase… You can also learn Git concepts and commands with a character-guided tutorial, simulate and run Git commands directly in the game, see their results applied in the game world in real time, and use AI to explain code you don’t understand.

If you or someone you know is a visual learner, beginner coder, or newer Git user, consider checking it out!

In this article, you’ll learn how to simplify your Git commands by using aliases.

Table of Contents

• Prerequisites

• What Are Git Aliases?

• How to Add Git Aliases Via the Global Git Configuration File (Recommended)

  • How to Set Your Preferred Git Editor

  • How to Open the Git Config File

  • How to Add a Git Alias Via Your Config File

• How to Add Aliases in the CLI

• How to Create Custom Commands for More Complex Shortcuts

  • How to Use Parameters in All Commands

• Other Useful Aliases

• Summary

Prerequisites

• Knowledge of Git.

• Git Bash installed (optional but recommended Windows users).

• An IDE like VS Code (this is also optional).

What Are Git Aliases?

Git aliases are custom shortcuts for existing Git commands, making common tasks quicker and easier. They let you define your commands, allowing you to tailor shortcuts exactly how you want.

You have two main options for adding/creating git aliases in your git configuration, using your Git configuration file or adding them directly via the CLI (terminal/command line).

How to Add Git Aliases Via the Global Git Configuration File (Recommended)

This option involves opening your global git config file and appending your git aliases to the bottom of the file.

How to Set Your Preferred Git Editor

Set your default Git config editor software, for example, I use VS Code to edit my Git configuration file, but you can use whatever text editor/code editor you prefer.

Run this command to set Notepad as your preferred editor on Windows (CMD/PowerShell):

git config --global core.editor "notepad"

Run this command to set VS Code as your preferred editor on Windows & MacOS /Linux:

git config --global core.editor "code --wait"

To set a different default editor, search online for “Set {editor} as default Git editor,” and replace {editor} with your preferred app.

How to Open the Git Config File

Open your terminal of choice and enter the following command. This will open the global Git config file (git config —global), in edit mode (-e).

git config --global -e

You can open the git configuration file directly from the following locations:

Mac Os: Home Directory → show hidden (Cmd + Shift + H) → .gitconfig

Windows: C:\Users\YourUsername\ → then show hidden files (in View) → and find .gitconfig

Linux: Home Directory → show hidden (Ctrl + H) → .gitconfig

How to Add a Git Alias Via Your Config File

If you're adding Git aliases for the first time, open your .gitconfig file, add [alias] at the end, and then list your shortcuts below. This tells Git these are aliases. Add your preferred alias (the shortened command you wish to run).

The format of a git alias is <alias> = <command>, so we have:

co = checkout
cob = checkout -b

Explanation of the above examples:

co = checkout this maps the git checkout command to a shorter git co command. You’d then call git co feature/123 in your terminal.

You do not need to type git in front of the command, as the configuration will pre-pend this automatically as it knows the command you’re mapping is a Git command.

Note: Any parameters passed to the command will be applied to the final command called within the alias only.

More aliases can be added in this way, mapping shortcuts to existing git commands. Saving and closing the file will then make the aliases available within your terminal.

How to Add Aliases in the CLI

If you want a more streamlined approach to adding Git aliases, you can add them directly from within the terminal/command line.

Taking the examples above, we can add these directly in the following way:

The format of the command is: git config --global alias.{alias} "{original command}":

git config --global alias.co "checkout"
#or
git config --global alias.cob "checkout -b"

It’s as easy as that!

How to Create Custom Commands for More Complex Shortcuts

Ok, this seems great, but it’s not really that impressive – we’re only removing a few characters. However, we can make them much more helpful, we can create our commands using shell commands.

Let’s take the following example, a command I use a lot!

new-work = !git checkout main && git pull && git cob

This alias combines multiple Git commands into one shell command. The ! character tells Git to treat it as a shell command, not a standard Git command.

Without !, Git treats the alias as a Git command (for example, checkout becomes git checkout). With !, Git knows to run it as a shell command without adding git in front.

By chaining these commands, we can write much more useful aliases. The one above will:

• First, check out the main branch.

• Using the && operator, it means the other commands will only run if the previous one has been successful.

• Secondly, it will pull down the changes from main.

• Finally, create a new branch from the main branch using our other alias git cob.

The final command can then accept parameters (as the original Git command would), so it can be used like so:

git new-work 'feature/new-work-from-main'

How to Use Parameters in All Commands

Up until now, we’ve only been able to pass our parameters to the final git command in our alias. However, what if we want to pass parameters to some, if not all of the commands within the alias? We can achieve this by using a shell function.

Take the following example:

new-work = "!f() { git checkout \"$1\" && git pull && git checkout -b \"$2\"; }; f"

Above we’re using a shell function that processes input parameters.

Explanation:

1. !f():

   • The ! tells Git to interpret the alias as a shell command rather than a standard Git command.

   • f() defines a shell function f that will allow us to execute multiple commands in sequence.

2. Everything inside { } is what will be executed within the f() function.

3. git checkout \”$1”'\: Will run a parameterized Git command, where $1 is escaped and will be replaced with the 1st parameter passed to the alias. The \" escape sequences around $1 allow for branch names with spaces.

4. && is a logical operator that ensures each command only runs if the previous one succeeds. If git checkout "$1" fails, the commands that follow won’t run.

5. git checkout -b \”$2”\ : Creates a new branch with the name of the second parameter as before.

6. ;: Marks the end of the f() function;

7. f: The final f calls the alias function immediately, meaning that when you call the alias, it declares the function and then calls it immediately.

Usage:

git new-work development task/feat-123

Other Useful Aliases

[alias]
     co = checkout
    cob = checkout -b
    s = status
    tidy-up = !git checkout main && git branch | grep -v "main" | xargs git branch -D
    latest = !git checkout main && git pull
    new-work = "!f() { git checkout \"$1\" && git pull && git checkout -b \"$2\"; }; f"
    done = !git push -u origin HEAD
    save = !git add -A && git commit
    saveM = !git add -A && git commit -m
    br = branch --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) - %(contents:subject) %(color:green)(%(committerdate:relative)) [%(authorname)]' --sort=-committerdate

Summary

co: Checkout given branch → git co task/feat-123

cob: Creates a new branch from the current branch → git cob feature/123

s: Calls git status to view the status of the current git branch → git s

tidy-up: Deletes all local branches other than main → git tidy-up

latest: Gets the latest changes from remote main branch → git latest

new-work: Creates a new branch (2nd param) from 1st param branch → git new-work main feat/123

git done: Pushes the current branch to the remote repository (origin) and sets it as the upstream branch. This can be helpful when pushing your first commit and you get the error:
fatal: The current branch has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin

save: Will simply add all changed files, and commit them, opening your default Git editor and requesting a commit message → git save

savem: Will do as above, but instead of opening your editor, you can pass in a commit message inline → git savem ‘Task123: add index.html

br: This one looks complicated, but it’s not as complicated as it seems but does highlight the power of aliases. In essence, it customizes the output format of git branch to display a detailed, color-coded list of branches, sorted by the most recent commit date, it will look something like the image below for each branch you have locally.

There you have it, an introduction to Git aliases and some useful examples of aliases you can add as a starter to your configuration.

As always if you want to chat about it, or hear about future articles you can follow me on Twitter.

When code becomes difficult to read or change, it slows down progress and can even cause bugs. To keep a codebase healthy and easy to work with, you’ll need to take care of it.

Improving and organizing old code can feel like a big task, but there are tools and methods that can make it easier. This guide will show how to refresh your codebase step by step which will make it simpler to work with and less likely to cause issues.

Table of Contents

1. How to Review Your Code Effectively

2. How to Identify Technical Debt and Problem Areas in Code

3. How to Measure Code Quality with Code Analysis Tools

4. AI Tools to Help You Improve Your Code

5. Version Control Best Practices for Code Changes

6. Conclusion

How to Review Your Code Effectively

Code reviews are essential for catching issues early, improving readability, and ensuring long-term maintainability. Reviewing your own code or someone else’s involves more than just scanning for errors – you’ll also want to make sure each part is clear, efficient, and follows good practices.

Here’s a step-by-step approach to help you review code effectively, with practical strategies, tools, and what to look for during the process.

Strategies for Effective Code Review

1. Break Down the Review Process: Reviewing code all at once can be overwhelming, especially in large projects. Focus on small sections of the codebase at a time, such as individual functions or modules. This approach helps you examine each part closely and avoids missing issues that could be overlooked in a quick scan.

2. Review for Clarity and Simplicity: Good code should be easy to read and understand. When reading through the code:

   • Variable and Function Names: Are variable names descriptive enough to convey their purpose? Long, unclear names make code harder to follow.

   • Function Length: Keep functions short and focused on one task. Long functions are harder to debug and maintain.

   • Comments and Documentation: Comments should explain why something is done rather than what is happening, which should be clear from the code itself. For instance, avoid excessive commenting on trivial lines and focus on complex logic or business rules.

3. Check for Code Reusability and Modularity: Look for repeated code or functions performing multiple tasks. By modularizing code, you make it easier to test, update, and reuse. In a review, look for:

   • Duplicate Code: Repeated code can often be refactored into a function.

   • Single Responsibility: Each function should handle one task, making it easier to maintain and update.

4. Examine Error Handling and Edge Cases: Robust code should handle unexpected inputs or errors gracefully. During a review, think about potential edge cases that could break the code:

   • Null or Undefined Values: Does the code check for undefined values where needed?

   • Out-of-Range Errors: Ensure array indexes and calculations won’t produce errors with edge cases.

   • Error Messages: Make sure error handling is meaningful, with clear error messages where applicable.

5. Look for Performance Issues: Performance may not always be critical, but it’s good to check for potential bottlenecks. Look for:

   • Loop Optimization: Avoid deeply nested loops or repeated work inside loops.

   • Database Queries: Minimize unnecessary database calls.

   • Heavy Computation in the Main Thread: Move any heavy processing outside the main application thread if possible.

6. Ensure Consistency with Coding Standards: Following a consistent coding style improves readability across the team. Many teams use linters or style guides to enforce these standards. Look for:

   • Code Format: Consistent indentation, spacing, and use of braces.

   • Naming Conventions: Follow agreed naming conventions (camelCase, snake_case, and so on) consistently.

Tools to Assist with Code Reviews

There are a number of tools out there that can help streamline your code reviews, whether you’re checking your own code or collaborating with others:

1. Linters (like ESLint and Pylint)

Linters check for syntax errors, code smells, and style guide violations. They are especially useful for catching minor issues, like inconsistent formatting or unused variables. We will discuss ESLint more in an upcoming section.

# Example: Run ESLint on a JavaScript project
npx eslint src/

2. Static Analysis Tools (like SonarQube)

These tools analyze code for deeper issues like security vulnerabilities, code duplication, and complex functions that might need refactoring.

# Configuring SonarQube to scan a project
sonar.projectKey=my_project
sonar.sources=src
sonar.host.url=http://localhost:9000
sonar.login=my_token

3. Automated Testing Tools

Running tests can verify that code changes don’t introduce new bugs. Use testing frameworks like Jest for JavaScript, PyTest for Python, or JUnit for Java to confirm your code behaves as expected.

Example of Refactoring During Code Review

Let’s say you encounter a long function with multiple responsibilities. The goal is to split it into smaller, focused functions. Here’s how you can do that:

// Original: A single function that handles everything
function processOrder(order) {
    // Calculate total price
    let total = 0;
    order.items.forEach(item => {
        total += item.price * item.quantity;
    });

    // Apply discount
    if (order.discountCode) {
        total = total * 0.9; // 10% discount
    }

    // Send order confirmation email
    sendEmail(order.customerEmail, 'Order Confirmation', 'Your order total is ' + total);
}

// Improved: Break into smaller functions for readability and reusability
function calculateTotal(order) {
    return order.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

function applyDiscount(total, discountCode) {
    return discountCode ? total * 0.9 : total;
}

function sendConfirmationEmail(email, total) {
    sendEmail(email, 'Order Confirmation', 'Your order total is ' + total);
}

function processOrder(order) {
    let total = calculateTotal(order);
    total = applyDiscount(total, order.discountCode);
    sendConfirmationEmail(order.customerEmail, total);
}

Breaking down the process into smaller functions makes the code cleaner, more readable, and easier to test. Each function now has a single responsibility, which helps reduce bugs and makes future updates simpler.

How to Identify Technical Debt and Problem Areas in Code

Technical debt refers to the accumulation of issues within a codebase that arise when development shortcuts are taken, often to meet tight deadlines or speed up releases. While these shortcuts may enable quicker progress initially, they lead to complications down the line.

Technical debt requires proactive management. If you leave it unchecked, it can reduce productivity, create bugs, and slow down development.

Think of technical debt like financial debt: taking on debt can be helpful in the short term, but failing to address it or pay it down will lead to greater challenges.

Common causes of technical debt include:

• Rushed development cycles: When teams prioritize quick delivery over thorough design and testing, they may produce incomplete or hastily written code.

• Lack of planning for future changes: Sometimes, code is written without accounting for scalability, leading to issues as the project grows.

• Insufficient documentation or testing: Without proper documentation and test coverage, codebases become difficult to understand and validate over time.

• Outdated frameworks and dependencies: When frameworks or libraries aren’t updated, they can become incompatible with newer components or security standards, introducing risk and hindering future updates.

Types of Technical Debt

Technical debt manifests in different ways. Here are some common examples:

1. Code Duplication:

Repeated code across multiple places within a project can lead to inconsistencies, as fixing an issue or updating a feature in one area may not carry over to others. Refactoring duplicate code into reusable functions or components is an effective way to reduce this debt.

Example: In a web application, you might find similar code for user authentication scattered across different modules. Instead, centralizing this logic into a single authentication module ensures consistent updates.

2. Outdated Dependencies and Frameworks:

Using old libraries or frameworks can slow down development and introduce security vulnerabilities. Over time, dependencies may lose support or become incompatible with new features, making them costly to maintain.

Solution: Regularly update libraries and frameworks, and monitor for deprecations or vulnerabilities. This can be streamlined by using dependency managers, which help check for updates and security patches.

3. Complex, Long Functions with Multiple Responsibilities:

Large, complex functions that handle multiple tasks are difficult to understand, test, and modify. Known as “God functions,” these make debugging cumbersome and increase the risk of introducing new bugs.

Solution: Follow the Single Responsibility Principle (SRP). This means that each function or method should accomplish one task. Breaking down large functions into smaller, focused units makes the code easier to read and test.

Example: Instead of having a single processUserRequest function that handles authentication, logging, and database queries, split it into three functions: authenticateUser, logRequest, and queryDatabase.

4. Insufficient Error Handling:

Code that lacks proper error handling can lead to bugs and unexpected behavior, especially in larger systems. Without clear error messages, diagnosing and fixing issues can be challenging.

Solution: Include comprehensive error handling and ensure that meaningful error messages are displayed. Log errors in a way that helps developers track and diagnose issues.

5. Hardcoded Values:

Hardcoding values directly into code makes it difficult to adjust settings without modifying the source code. For example, using fixed URLs or credentials directly in the codebase can create security risks and maintenance headaches.

Solution: Use configuration files or environment variables to store values that might change. This improves security and allows for easy updates.

6. Lack of Documentation and Testing:

Documentation and testing are often neglected when time is short. But without proper documentation and test coverage, the code becomes challenging to understand and validate, slowing down development and increasing the risk of bugs.

Solution: Implement test-driven development (TDD) or include time in the development cycle for creating documentation and writing tests. Aim for at least basic test coverage for critical paths and functions.

How to Identify and Manage Technical Debt

Identifying technical debt is crucial if you want to address and improve it. Here are some strategies you can follow:

1. Code Reviews: Regular peer reviews help uncover areas of potential debt. In reviews, team members can flag complex code, lack of tests, or unclear logic, helping address these issues early.

2. Automated Static Code Analysis: Tools like SonarQube, Code Climate, and ESLint (for JavaScript) analyze codebases for code smells, vulnerabilities, and complexity. They’re effective for spotting issues like duplicate code, long functions, and outdated dependencies.

3. Regular Refactoring Sessions: Scheduling dedicated time for refactoring allows the team to improve existing code quality. During these sessions, focus on simplifying code, breaking down large functions, and removing duplicates.

4. Technical Debt Backlog: Track technical debt items in a backlog, prioritizing them alongside feature development. This backlog helps balance feature work with debt reduction and keeps everyone aware of existing debt.

How to Deal with Technical Debt in Code

Here’s a practical example to demonstrate how refactoring can help address technical debt, specifically by removing code duplication.

Example: Removing Duplicate Code

Let’s say we have two functions that send different types of emails but use repeated code:

# Duplicate code example
def send_welcome_email(user):
    send_email(user.email, "Welcome!", "Thanks for joining!")

def send_password_reset_email(user):
    send_email(user.email, "Password Reset", "Click here to reset your password.")

Each function has a similar structure, so refactoring can make the code cleaner and reduce duplication.

# Refactored code
def send_email_to_user(user, subject, message):
    send_email(user.email, subject, message)

# Use the refactored function
send_email_to_user(new_user, "Welcome!", "Thanks for joining!")
send_email_to_user(existing_user, "Password Reset", "Click here to reset your password.")

This example demonstrates how consolidation can reduce repetition and make the code more flexible.

How to Avoid Technical Debt

Proactively managing technical debt helps reduce it over time. Here are ways to avoid accumulating more debt:

• Establish Code Standards: Create and enforce coding standards within the team. Consistent practices reduce complexity, improve readability, and make it easier to identify issues early.

• Refactor Regularly: Rather than waiting for debt to accumulate, make minor improvements during routine work. A “leave it better than you found it” approach ensures code quality remains high over time.

• Encourage Thorough Testing: Strong test coverage identifies potential problems early, reducing the likelihood of code with hidden issues. Testing tools like Jest for JavaScript or PyTest for Python make it easy to add tests to each function and module.

• Plan for Scalability: Think about future needs when designing code. Avoid shortcuts that might restrict scalability and performance as the application grows.

• Limit Workarounds and Temporary Fixes: If temporary fixes are necessary, document them and prioritize removing them as soon as possible. Keeping track of these “quick fixes” ensures they don’t become long-term issues.

How to Measure Code Quality with Code Analysis Tools

Code quality tools can help you find issues that might not be obvious. They can point out things like unused variables, code that’s hard to read, or security problems. Popular tools include ESLint for JavaScript, Pylint for Python, and SonarQube for different programming languages.

Here’s how to set up a simple code check with ESLint:

1. Install ESLint:

    npm install eslint --save-dev
   

2. Initialize ESLint:

    npx eslint --init
   

   This command will prompt you to answer a few configuration questions. You can choose your preferred style guide and select a few options about your environment and file format.

3. Example Code with Issues

   Here’s a sample JavaScript file (example.js) with a few common issues:

    // example.js
   
    var x = 10;   // Unused variable
    let y = 5;
    const z = 'Hello World'
   
    function calculateSum(a, b) {
        return a + b
    }
   
    calculateSum(3, 4);
   
    // Missing semicolon and inconsistent indentation
    if(y > 3){
        console.log("Y is greater than 3")
    }
   

4. Run ESLint:

    npx eslint example.js
   

   After running this command, ESLint will analyze example.js and report any issues based on the configured rules.

5. ESLint Output

   ESLint provides detailed feedback about the issues it detects:

    /path/to/example.js
      1:5  warning  'x' is assigned a value but never used          no-unused-vars
      3:12  error    Missing semicolon                               semi
      6:25  error    Missing semicolon                               semi
      10:1  error    Expected indentation of 4 spaces but found 3    indent
      11:26 error    Missing semicolon                               semi
   
    ✖ 5 problems (4 errors, 1 warning)
   

   Here’s a breakdown of each issue detected by ESLint:

   • Unused Variable: ESLint identifies that x is declared but never used (no-unused-vars rule).

   • Missing Semicolons: ESLint flags lines where semicolons are missing at the end of statements (semi rule).

   • Inconsistent Indentation: ESLint notices that line 10 doesn’t follow consistent indentation (indent rule).

6. Fixing the Code

   Based on ESLint’s feedback, here’s the corrected code:

    // example.js
   
    let y = 5;
    const z = 'Hello World';
   
    function calculateSum(a, b) {
        return a + b;
    }
   
    calculateSum(3, 4);
   
    if (y > 3) {
        console.log("Y is greater than 3");
    }
   

   • We removed the unused variable x.

   • We added missing semicolons.

   • And we adjusted indentation for consistent spacing.

7. Re-run ESLint to Verify Fixes

   After making these changes, you can run npx eslint example.js again to confirm that there are no remaining issues. ESLint will return no output if everything is now clean, confirming that the code adheres to the configured standards.

Additional Tip: Auto-Fixing with ESLint

ESLint can automatically fix some issues for you. To do this, use the --fix flag:

npx eslint example.js --fix

This command will automatically correct issues like indentation, unused variables, and missing semicolons where possible. But it’s important to review the changes to ensure they align with your intended functionality.

Reviewing code, spotting technical debt, and using quality tools help keep the codebase healthy. If you follow these steps, your project will be easier to manage and less likely to break.

AI Tools to Help You Improve Your Code

Using AI tools to restructure code makes improving code quality much faster and easier. These tools help find issues, suggest changes, and can even automate some parts of the refactoring process.

I'll share some AI tools that can help you with code analysis, refactoring, and dependency management, based on my own experience and what I've found useful.

Best AI Tools for Code Restructuring

AI-powered tools are becoming more common, and they offer different ways to boost code quality and simplify refactoring. Here are some I've found helpful:

1. GitHub Copilot

GitHub Copilot is like a coding assistant that provides smart suggestions as you write code. It can complete code snippets, suggest new functions, and help rework existing code to make it more efficient. I’ve found it useful for writing repetitive code blocks or coming up with quick refactorings.

For example, let’s say you need to rewrite a function to be more efficient:

# Original function that checks if a number is prime
def is_prime(n):
    if n < 2:
        return False
    for i in range(2, n):
        if n % i == 0:
            return False
    return True

GitHub Copilot might suggest optimizing the function like this:

# Optimized version suggested by Copilot
def is_prime(n):
    if n < 2:
        return False
    for i in range(2, int(n**0.5) + 1):
        if n % i == 0:
            return False
    return True

The updated version checks factors only up to the square root of n, making it faster for large numbers.

2. QodoGen

QodoGen provides automated suggestions for refactoring and can detect common code issues, like unused variables or large functions doing too many tasks. It also helps split complex code into smaller, more manageable pieces and can explain sections of the code base or the entire codebase which will facilitate the restructuring process.

This tool is capable of doing this because, unlike other AI assistants and general purpose code generation tools, Qodo focuses on code integrity, while generating tests that help you understand how your code behaves. This can help you discover edge cases and suspicious behaviors, and make your code more robust.

For example, if you have a function handling multiple tasks, QodoGen might suggest breaking it down:

# Before refactoring
def handle_user_data(user_data):
    validate_data(user_data)
    save_to_database(user_data)
    send_welcome_email(user_data)

# After refactoring
def handle_user_data(user_data):
    validated_data = validate_data(user_data)
    save_data(validated_data)
    notify_user(validated_data)

Separating the steps makes the code easier to maintain and test.

3. ChatGPT for Code Assistance

ChatGPT can act as a helpful companion when working on code restructuring tasks. Arguably the most used coding assistant, it provides advice on refactoring strategies, explains how to implement changes, or offers example snippets. It’s like having an expert to consult whenever you need guidance or ideas.

For instance, if you’re unsure how to optimize a function or restructure a class, ChatGPT can provide sample code or describe best practices. You can also ask it for help with understanding errors or fixing specific problems in your code.

Just make sure you double-check the code it provides (same goes for all these AI assistants) as it can hallucinate and make mistakes.

Automated Tools for Refactoring and Analysis

AI tools not only assist with writing code but also with analyzing it for quality improvements:

1. SonarQube

SonarQube scans the code to detect bugs, vulnerabilities, and code smells. It generates reports with suggestions on what to fix, helping maintain a healthy codebase.

# Sample SonarQube configuration
sonar.projectKey=my_project
sonar.sources=src
sonar.host.url=http://localhost:9000
sonar.login=my_token

2. ReSharper

This tool integrates with Visual Studio and offers automatic refactoring options. It highlights code that can be simplified or cleaned up and suggests ways to optimize the codebase.

3. DepCheck for Dependency Management

AI tools like DepCheck help find unused dependencies in JavaScript projects, keeping package files clean.

# Running DepCheck to find unused dependencies
npx depcheck

How These Tools Help with Code Restructuring

Using AI tools like GitHub Copilot, QodoGen, and ChatGPT speeds up the process of code restructuring. They provide suggestions that save time and catch issues early, making the code easier to maintain.

Combining these tools with automated analysis tools like SonarQube and ReSharper ensures all aspects of the codebase are covered, from quality checks to refactoring.

These AI tools have other features that facilitate this process: for example, they all have a chat feature that lets you ask questions and get replies about your code and any best practices you should be following. Also, QodoGen allows you to add parts of or the whole codebase for context with the click of a button, along with other features for test generation and pull request reviews.

When restructuring your codebase, having a variety of AI tools can make the process smoother and more efficient. This is AI usage at its best.

Version Control Best Practices for Code Changes

Version control keeps track of code changes, making it easier to manage updates, collaborate with others, and fix issues. Following some best practices can help maintain a clean and organized codebase.

Let’s look at how to manage code changes, track updates, and ensure quality through code reviews.

Using Git Branching Strategies to Manage Code Changes

Git branching helps keep different versions of the code separate, allowing multiple developers to work without affecting the main codebase. Here are some common strategies:

1. Feature Branching

Feature branches allow developers to work on a new feature without changing the main codebase. Each feature gets its own branch, and once complete, it can be merged into the main branch.

# Creating a new feature branch
git checkout -b feature/new-login-page

# Working on the new feature and then committing changes
git add .
git commit -m "Added login page UI"

# Merging the feature branch into the main branch
git checkout main
git merge feature/new-login-page

2. GitFlow Strategy

This strategy involves using multiple branches for different stages of development, such as feature, develop, and release. It separates development work and allows smoother integration and deployment.

• Main Branch: Contains production-ready code.

• Develop Branch: Holds the latest completed work, ready for the next release.

• Feature Branches: Created from the develop branch for new features.

Example:

# Switch to the develop branch
git checkout develop

# Create a new branch for a feature
git checkout -b feature/upgrade-search

# Commit changes and push the feature branch
git add .
git commit -m "Improved search feature"
git push origin feature/upgrade-search

How to Track and Document Code Updates

Documenting code changes helps keep the team informed and makes it easier to understand what was done later. Here are some tips for tracking updates:

1. Writing Clear Commit Messages

Commit messages should explain what was changed and why. A clear message helps others know the purpose of each update.

Example:

# Good commit message
git commit -m "Fixed bug that caused login failure on mobile devices"

# Bad commit message
git commit -m "Fixed bug"

2. Using Tags to Mark Releases

Tags can be used to label important points in the project’s history, such as release versions. This makes it easier to find stable versions of the code.

# Create a tag for version 1.0
git tag v1.0

# Push the tag to the remote repository
git push origin v1.0

3. Creating and Using Changelogs

A changelog lists the changes made in each version, helping developers and users see what was updated or fixed.

Example format for a changelog:

## [1.0.1] - 2024-10-01
### Added
- New login feature

### Fixed
- Resolved search issue on homepage

### Changed
- Updated user dashboard layout

Importance of Code Reviews in Maintaining Code Quality

Code reviews help catch errors, share knowledge, and ensure code stays clean and maintainable. Here are some practices to follow for effective code reviews:

1. Keep Code Changes Small

Smaller changes are easier to review, making it more likely to spot mistakes. Large changes can be broken down into smaller parts.

2. Use Pull Requests for Reviews

Pull requests create a space for discussion around changes. Team members can review the changes, suggest improvements, and approve the updates.

# Push the feature branch to the remote repository
git push origin feature/new-feature

# Create a pull request on GitHub, GitLab, or Bitbucket

3. Provide Constructive Feedback

Code reviews should aim to improve the code without discouraging the developer. Suggest better ways to solve problems and explain the reasoning.

Example comments during a code review:

• "Consider using a list instead of a dictionary for this data structure, as it simplifies the code."

• "This function is doing multiple tasks. It might be clearer if we split it into two separate functions."

Using these practices helps ensure code changes are managed effectively, updates are well-documented, and the quality of the codebase remains high. Regular code reviews and proper branching strategies make it easier for teams to collaborate and keep the project on track.

Conclusion

Reviving and restructuring a codebase can seem like a big task, but taking small, planned steps makes it manageable. Start by checking the current state of the code and making a list of areas that need work. Set clear goals and create a plan to improve the code, step by step.

Using the tools we discussed here can help find issues, suggest changes, and even automate some tasks. Version control practices, such as branching strategies and code reviews, keep changes organized and ensure the quality stays high.

With a solid approach, even the messiest codebase can become clean, efficient, and easier to work with.

Resources

• AI tools have been developed to assist with the Git branching, Pull Request reviews and approval. Check out this article to read more on one of my favorites.

• If you want a step by step tutorial on how to revive and refactor your code, check out this youtube video.

• Check out this freecodecamp article on code restructuring to dive deeper.

Connect with me on LinkedIn, Twitter, and my peronal blog if you found this helpful.

In this article, you’ll learn all about the git stash command and why it’s important to stash your code. By the end of this article, you will have firsthand knowledge of how to use the git stash command in your projects.

Here’s what we’ll cover:

1. Why do we stash?

2. Pros and cons of using git stash

3. How to create a stash in Git (step-by-step guide)

4. Other git stash commands like list, apply, and pop

5. How to handle multiple stashes in your project

6. Real use cases for git stash

7. Conclusion

Why Do We Stash?

Git has provided us with the stash command, which makes our lives easier. The git stash command helps you save a draft of your current task, temporarily giving you time to attend to your new task without losing your progress on the previous task.

There are so many reasons why stashing is important. Here are some of them:

• Resolving Conflicts within a Project: In a collaboration setting, you, as a developer, get to work with other developers on a particular project. A merge conflict might occur, which might require you to pause your current task to handle the conflict. You can easily stash your current task and focus fully on resolving the merge conflict without having to worry about losing your progress.

• Clean Working Environment: You might want to start up a new task or want to pull a repository into your working environment. With stashing, you can clear your current working environment temporarily, making your work environment clean and ready to perform another task.

• Switching branches: Git stash is very useful in this situation. You might be in the middle of something and it's not ready to be committed, but at that moment, you need to switch branches. With git stash, you can easily move to another branch and perform your other tasks.

Pros and Cons of Stashing

Here are some of the pros (advantages) of using stash:

• It’s easy to use and understand

• It helps you save a draft of your current task and focus on another task.

• It comes in handy when trying to resolve conflicts like merge conflicts, git fork, and so on when working with other collaborators in a project.

• You can reapply your draft file not only on the branch you stashed it from but also on other branches.

As the saying goes "Anything that has an advantage also has a disadvantage". Here are some of the cons (disadvantages) of using stash:

• Stashing can lead to a merge conflict: A merge conflict can occur when reapplying your stashed draft to a branch which already has similar content to the draft, and you’ll need to resolve this manually.

• Cluster and Confusion: In a situation where you are working on a huge project with multiple sub-tasks, applying the stash command at various points might lead to a cluster of saved drafts. This can lead to confusion on the particular saved draft you would want to continue working on.

Now that we have seen some of the pros and cons of using git stash, let’s look at how git stash works and how to apply it to our project.

How Git Stash Works

As we just discussed, git stash helps you save a draft of your current uncommitted changes. Now let's see how this happens using the analogy below.

When you run the git stash command, it puts your tracked file in a box and then removes/hides that box, making the environment/branch clean and free to use for another task. When you apply the stash command to the current branch you are working on, it saves a draft of all tracked files in that branch and reverts that branch to a clean slate.

To explain better, here’s an example:

From the image above, we created a new project and already initialized git in it. We are currently on the "main" branch which is the default branch.

If we modify a file in the main branch and apply the git stash command, the modified file will be saved as a draft and your working environment will be reverted to the last commit you made (making it look like there was no modification in the first place).

Note: By default, you can only apply the stash command to tracked files in git.

How to Create a Stash

Here is how you can go about creating a stash in your project.

Create a file you want to work on, maybe an index.html file or a style.css file. Initialize git in your project by running the command git init. Add the file to the Git tracking stage by running git add . Then at this point, if you make any modifications and would like to come back later to complete it, you can run:

git stash

Here is a visual representation of the above process:

There are other stash commands you should know in order to control your stashed project. They include List, Pop, Clear, Apply, Show, and a few others.

• List: The list command is mainly used to display the number of stashes made in a particular project. Just like an array, the stashed draft is numbered from 0 upwards. To use this command, run git stash list. Note: The stash command is arranged in such a way that when a change is stashed, it takes up the first position i.e."stash@{0}" while the other changes are pushed down.

• Pop: This command is used to retrieve an already stashed draft back into your project. When you apply the pop command, it automatically retrieves the latest stashed draft back into your working project and removes it from the stash list. Run the following command to pop a stash: git stash pop.

• Clear: When applied, this command is used to remove/delete all the stash entries. It is important to note that, when you use the clear command, you can recover the cleared stash again. You can use it by running this command: git stash clear.

• Apply: This command works just like the pop command, but the only difference is that the stashed draft is not removed from the list after it has been retrieved. This means that when you use the apply command, it retrieves the latest stashed draft back into your project but doesn't remove it from the stash list. Run the following to use the apply command: git stash apply.

• Show: This command is important because it helps show you the changes you made in the stashed draft. Use the following command to show a stash: git stash show.

How to Handle Multiple Stashes in Your Project

Knowing how to handle multiple stashes in your project is important, as there may be times when you have more than 3-4 stashed drafts in your project.

Here is how to handle multiple stashes:

Step One: Customize each stash with a specific message

This step is very important if you would like to avoid being confused in situations where you have multiple stashes.

From the image above, we have a total of four stashes (that is, "stash@{0}" to "stash@{3)") and each stash bears the same message of "first commit". This might be confusing when we might want to pop or apply one of these stashes later in the future.

To sort this issue, all we have to do is assign a specific stash message to the next stash. We can do this by running the following command:

git stash save "New message/name goes here"

Here is how it looks:

From the image above, you can clearly see the difference between the two latest stashes (that is, "stash@{0}" and "stash@{1}") and the others. The first two stashes have their own specific message, which makes it very easy to differentiate them from the rest.

Step Two: Retrieve a specific stash instead of the latest stash

There are situations when you might want to retrieve a specific stashed draft rather than the latest stashed draft you just made. You can do this by using either:

git stash pop stash@{n}

or

git stash apply stash@{n}

Where n indicates the stash ID you want to retrieve. This also works when you want to delete or clear a specific stashed draft.

Step Three: Preview your stashed draft before you retrieve it.

Before you restore a stashed draft, it is important to preview it to ensure that it's the exact draft you want to restore. The show command helps you review the changes in the draft before restoring it. To do this, run the following command:

git stash show stash@{n}

Real Use Cases for git stash

Here are some real-life case scenarios of when the git stash command is important.

• During Debugging: This happens a lot when you are in a collaboration setting. Let's say you are working with extra two developers on a project and one of them happens to encounter an error that needs your urgent attention. Using the git stash command is ideal in this situation.

• When you are not ready to Commit: This occurs often. There are situations where you are not ready to commit your changes to the repository. Stashing those changes is the best next step.

• Returning the directory to its original state: Returning the directory to its original state simply means cleaning out all changes made to the directory and making it look as if nothing was done to it. The git stash command helps you achieve this.

Conclusion

The git stash command effortlessly helps you manage your project properly whether you are working alone or you’re in a collaboration setting.

This tool is vital to every developer who wants to flow freely and effortlessly while working on a project.

At this point, I believe you know what git stash is all about, why it is important and how to make use of it in your project.

Thank you for reading.

Contributing to open source projects is not just a way to give back to the community – it's also an excellent opportunity to enhance your skills, build your portfolio, and connect with like-minded developers from around the world.

But for many beginners, the prospect of contributing to open source can be daunting. Common barriers include not knowing where to start, fear of making mistakes, or feeling intimidated by complex codebases.

This guide aims to break down these barriers and provide you with a clear path to making your first open source contribution.

What we’ll cover:

1. Understanding Open Source

2. How to Prepare for Your First Contribution

3. How to Find the Right Open Source Project

4. Understand the Project Guidelines

5. How to Make Your First Contribution

6. Best Practices for Open Source Contribution

7. Practical Tools for Getting Started

8. Continuing Your Open Source Journey

9. Conclusion

Understanding Open Source

What is open source?

Open source refers to software whose source code is freely available for anyone to view, modify, and distribute. This collaborative approach to software development has led to the creation of many powerful tools and platforms we use daily, such as Linux, WordPress, and TensorFlow.

Benefits of contributing to open source projects

Contributing to open source projects offers numerous advantages for developers. It's an excellent way to improve your skills, exposing you to diverse coding styles and best practices. Your contributions can also help you build a strong portfolio, providing tangible proof of your abilities to potential employers.

The open source community offers valuable networking opportunities, connecting you with developers worldwide and potentially leading to job opportunities or mentorships. By contributing, you also give back to the community, helping improve tools that you and others rely on daily.

Lastly, you gain insights into project management, learning how large-scale software projects are coordinated and maintained. These benefits collectively enhance your technical skills, career prospects, and understanding of the software development ecosystem.

How to Prepare for Your First Contribution

Set up your development environment

1. Choose a code editor or IDE (Integrated Development Environment) that you're comfortable with. Popular options include Visual Studio Code, Sublime Text, or JetBrains IDEs.

2. Install Git on your computer. Git is the most widely used version control system in open source projects.

Learn version control basics (Git):

Understanding Git is crucial for contributing to open source. Here are some key concepts to start with:

• Repository: A project's folder containing all files and version history.

• Clone: Creating a local copy of a repository on your machine.

• Branch: A separate line of development for new features or bug fixes.

• Commit: Saving changes to your local repository.

• Push: Uploading your local changes to the remote repository.

• Pull Request: Proposing your changes to be merged into the main project.

Take some time to practice these concepts on a personal project before diving into open source contributions.

How to Find the Right Open Source Project

Identify your skills and interests:

Start by listing your skills (programming languages, frameworks, design, documentation) and areas of interest. This will help you find projects that align with your abilities and passions.

Explore resources for finding projects:

While we'll introduce some specific tools later in this guide, here are some general platforms you can explore to find open source projects:

1. GitHub's "Explore" section

2. CodeTriage

3. Up For Grabs

4. First Timers Only

5. Your favorite software's repository (look for "good first issue" labels)

Remember, the key is to find a project you're genuinely interested in, as this will keep you motivated throughout the contribution process.

Understand the Project Guidelines

Before you start contributing to an open source project, it's crucial to understand the project's guidelines. These guidelines are typically found in files like CONTRIBUTING.md, CODE_OF_CONDUCT.md, or in the project's README file.

Read the Contribution Guidelines

The CONTRIBUTING.md file is your roadmap to becoming a valuable contributor. It usually contains information on:

• How to set up the project locally

• The process for submitting contributions

• Coding standards and style guides

• How to report bugs or suggest new features

• Communication channels for the project

For example, the popular open source library React has a comprehensive CONTRIBUTING.md file. It includes sections on:

• Code of Conduct

• Development Workflow

• Bugs

• Proposing a Change

• Sending a Pull Request

Familiarize Yourself with Project Structure and Coding Standards

Take time to understand the project's architecture and file organization. This might involve:

1. Exploring the directory structure

2. Reading documentation on the project's architecture

3. Reviewing existing code to understand the coding style

Many projects use automated tools to enforce coding standards. For instance, a JavaScript project might use ESLint for code linting. You might see a configuration file like .eslintrc.js in the project root:

module.exports = {
  "extends": "airbnb",
  "rules": {
    "react/jsx-filename-extension": [1, { "extensions": [".js", ".jsx"] }],
    "no-console": "off"
  }
};

This configuration tells you that the project follows Airbnb's JavaScript style guide with a few custom modifications.

How to Make Your First Contribution

Let's walk through the process of making your first contribution, using a real-life example.

Choose an Issue

Suppose you've found an issue in the repository of a popular markdown editor. The issue is labeled "good first issue" and describes a bug where the preview doesn't update when the user types a backtick (`).

Communicate with Project Maintainers

Before starting work, you comment on the issue:

Hi there! I'm new to open source and would love to work on this issue. 
Is it still available? I'm thinking of approaching it by modifying the 
event listener for the editor component. Does that sound like a good approach?

A maintainer responds, welcoming you and confirming your approach.

Create a Fork and Work on Your Solution

1. Fork the repository to your GitHub account.

2. Clone your fork locally:

    git clone https://github.com/yourusername/markdown-editor.git
   

3. Create a new branch:

    git checkout -b fix-backtick-preview
   

4. Make your changes. For example, you might modify the editor component:

    class Editor extends React.Component {
      handleChange = (event) => {
        const { value } = event.target;
        this.props.onChange(value);
   
        // Force update preview on backtick
        if (value.endsWith('`')) {
          this.props.forceUpdatePreview();
        }
      }
   
      render() {
        // ... rest of the component
      }
    }
   

5. Commit your changes:

    git add .
    git commit -m "Fix: Update preview on backtick input"
   

6. Push to your fork:

    git push origin fix-backtick-preview
   

Submit a Pull Request

1. Go to the original repository on GitHub.

2. Click "New pull request" and select your branch.

3. Fill in the pull request template:

    ## Description
    This PR fixes the issue where the preview doesn't update when a backtick is typed.
   
    ## Changes
    - Modified the Editor component to force an update when a backtick is entered
   
    ## Testing
    1. Open the editor
    2. Type some text followed by a backtick
    3. Verify that the preview updates immediately
   
    Fixes #123
   

4. Submit the pull request and wait for feedback.

Best Practices for Open Source Contribution

Write Clear Commit Messages

Good commit messages are crucial for project maintainability. Follow these guidelines:

• Use the imperative mood in the subject line

• Limit the subject line to 50 characters

• Capitalize the subject line

• Do not end the subject line with a period

• Separate subject from body with a blank line

• Wrap the body at 72 characters

• Use the body to explain what and why vs. how

Example of a good commit message:

Fix race condition in connection pool

- Add mutex lock when accessing shared resource
- Implement retry mechanism for failed connections

This change prevents multiple threads from accessing the connection
pool simultaneously, which was causing occasional crashes in high
load scenarios. The retry mechanism improves resilience to temporary
network issues.

Document Your Changes

Clear documentation is as important as good code. Here are some best practices:

1. Update relevant README files

2. Add inline comments for complex logic

3. Update or create API documentation for new features

For example, if you've added a new function to a Python library:

def validate_email(email: str) -> bool:
    """
    Validate an email address.

    Args:
        email (str): The email address to validate.

    Returns:
        bool: True if the email is valid, False otherwise.

    Example:
        >>> validate_email("user@example.com")
        True
        >>> validate_email("invalid-email")
        False
    """
    # Implementation details...

Respond to Feedback

When you receive feedback on your pull request:

1. Respond promptly and politely

2. Address all comments, even if just to acknowledge them

3. If you disagree with a suggestion, explain your reasoning respectfully

4. Make requested changes and update your pull request

For example:

Reviewer: "Could you add a unit test for the new validate_email function?"

You: "Absolutely, that's a great suggestion. I'll add a comprehensive test suite for various email formats and edge cases. I'll push the changes shortly."

Practical Tools for Getting Started

Git Begin: Your Gateway to Open Source Contributions

To help you take your first steps in open source, I’ve developed Git Begin, a free web application designed to make finding your first contribution opportunity as easy as possible.

How Git Begin works:

1. Visit Git Begin

2. Select your preferred programming language or framework from the options provided.

3. Browse through a curated list of issues tagged as "good first issue" or "beginner-friendly" across various open source projects.

4. Each issue is presented with key information such as the project name, issue description, and required skills.

5. When you find an issue that interests you, click on it to be directed to the original issue on GitHub.

Git Begin eliminates the overwhelming process of searching through countless repositories. It presents you with targeted, beginner-friendly opportunities that match your skills and interests, making it easier than ever to start your open source journey.

A Real-World Project for First-Time Contributors

In addition to Git Begin, I’m excited to introduce you to another free, open-source project designed specifically for beginners to practice their skills and make meaningful contributions:

• Project: Job Scraper

• Description: A tool for scraping job listings from multiple company career pages

• Repository: https://github.com/The-Enthusiast-404/career-craft-scrapper

About the project:

This Job Scraper project is a crucial component of a larger, ambitious platform I’m helping develop that will revolutionize the job-seeking process. This free platform aims to be a comprehensive resource for job seekers, offering a range of tools to streamline their job search and application process.

The Job Scraper itself aggregates job listings from various company career pages, forming the foundation of our platform. But that's just the beginning. Our vision extends to creating a full-fledged ecosystem that will include:

1. A centralized job application system, allowing users to apply to multiple positions across different companies seamlessly.

2. AI-powered resume creation tools to help job seekers craft compelling CVs tailored to their target roles.

3. An innovative AI mock interviewer, capable of simulating interviews for specific roles and tech stacks, helping candidates prepare more effectively.

By contributing to the Job Scraper project, you're not only gaining valuable experience in web scraping and data processing but also playing a part in building a platform that will make a real difference in people's careers.

It's an opportunity to work on a project with immediate practical applications while also contributing to a larger vision of making job seeking more accessible and efficient for everyone.

As an open source contributor, you'll have the chance to work on various aspects of this system, from improving the scraping algorithms to potentially helping develop some of the AI-powered features in the future.

This project offers a unique blend of practical coding experience and the satisfaction of working on a tool that will directly impact job seekers worldwide.

Current contribution opportunities:

There are a number of "good first issues" available, all focused on web scraping tasks. These might include:

• Adding support for scraping job listings from a new company's career page

• Improving the data cleaning process for a specific job site

• Enhancing the scraper's resilience against changes in a website's structure

Each issue is carefully documented to help newcomers understand the task and its context within the larger project.

First Steps in Open Source

The Job Scraper project has become a welcoming entry point for many developers making their first open source contributions. To date, we've had several contributors who chose the repository for their first pull request, most of them being students eager to gain real-world experience.

These newcomers to open source have successfully added new scraping functionalities, improved existing algorithms, and enhanced our data processing capabilities.

Their achievements demonstrate that our repository is an ideal starting point for anyone looking to begin their open source journey, especially students wanting to apply their skills to a practical project.

How to get involved:

1. Visit the repository: https://github.com/The-Enthusiast-404/career-craft-scrapper

2. Read through the README and CONTRIBUTING.md files to understand the project and contribution guidelines

3. Browse the open issues labeled "good first issue"

4. Comment on an issue you'd like to work on, and I will guide you through the next steps

Remember, both Git Begin and the Job Scraper project are completely free resources. We're committed to providing a supportive environment for developers to learn and grow in their open source journey.

Continuing Your Open Source Journey

Building on your first contribution:

After making your first contribution, take some time to reflect on what you've learned. Consider:

• What aspects of the process did you find challenging?

• What new skills or knowledge did you gain?

• How can you apply this experience to future contributions?

Use these insights to guide your next steps in open source.

Become a regular contributor:

To become a regular contributor:

1. Set up project notifications to stay informed about new issues and discussions.

2. Participate in project discussions, offering insights or asking questions.

3. Take on increasingly complex issues as you become more familiar with the project.

4. Help other newcomers by answering questions or reviewing their pull requests.

5. Consider contributing to documentation or writing tests, which are often overlooked but crucial aspects of open source projects.

Explore new projects:

As you gain confidence, don't hesitate to explore new projects:

1. Look for projects in different domains to broaden your skills.

2. Consider contributing to tools or libraries you use in your daily work.

3. Explore projects with different scales - from small utilities to large frameworks.

Remember, each project offers unique learning opportunities and challenges.

Conclusion

Contributing to open source can be an incredibly rewarding experience. It allows you to improve your coding skills, collaborate with developers worldwide, and make a meaningful impact on projects used by millions of people.

Remember, everyone starts somewhere. Don't be afraid to make mistakes – they're part of the learning process. The open source community is generally welcoming and supportive of newcomers.

We hope this guide, along with tools like Git Begin and our Job Scraper project, will help you take your first steps into the world of open source contribution. Happy coding, and we look forward to seeing your contributions!

Resources:

• Git Begin: https://gitbegin.theenthusiast.dev

• Job Scraper Project: https://github.com/The-Enthusiast-404/career-craft-scrapper

• Git Documentation: https://git-scm.com/doc

• GitHub Guides: https://guides.github.com/

• Open Source Guide: https://opensource.guide/

You can also download the Git Cheat Sheet in PDF format (along with some other resources) for free by joining my newsletter at flaviocopes.com/access.

Table of Contents

• Preface

• Basic Git Commands

• The Working Directory and the Staging Area

• Working with Branches

• Merging in Git

• Git Remotes

• Amending Commits

• Stashing in Git

• Git Tagging

• Reverting Changes in Git

• Viewing History Logs

• Git Diffs

• Git Flow

• Exploring Git References

• How to Configure Git

• Git Security

• How to Set Aliases in Git

• Rebasing in Git

• What is Cherry-Picking?

• Patching in Git

• Relative Dates in Git

• Git Blame

• Archiving in Git

• How to Track Files in Git

• Index Manipulation in Git

• Squashing in Git

• Data Integrity in Git

• Cleaning Up in Git

• Git Subtree

• How to Search in Git

• Bisecting in Git

• Git Attributes

• Git Checkout

• Git Reflog

• How to Handle Untracked Files in Git

• Force Pushing in Git

• Git Fetching and Pulling

• How to Handle Merge Conflicts in Git

• Working Trees in Git

• Submodules in Git

Preface

Welcome to this Git Cheat Sheet! It's an extensive guide I created to help empower both novice and seasoned developers with the knowledge you need to effectively utilize Git, the most popular version control system in the software industry.

This cheat sheet is designed to be your go-to resource, whether you're managing a solo project or collaborating within a large team. By providing clear explanations and practical examples, it should help demystify Git's complexities and transform them into intuitive, actionable insights.

Throughout this guide, you will explore a wide array of Git commands and concepts that form the backbone of software version control. From fundamental operations like initializing repositories and committing changes, to more advanced techniques such as branching, merging, and rebasing, this cheat sheet covers it all.

You'll also delve into specialized topics like squashing commits, bisecting to debug, handling submodules, and implementing subtrees. All this will help ensure that you're well-prepared to tackle any challenge that arises in your development process.

As you progress, you'll learn how to maintain data integrity, manage multiple working trees, and resolve merge conflicts efficiently. By the end, you'll not only have a deeper understanding of Git but also the confidence to use it to streamline your workflow and enhance collaboration with peers.

Prerequisites

To fully benefit from this cheat sheet, you should have a foundational knowledge of command-line operations and general programming principles. You should also be familiar with using a terminal or command prompt so you can better understand and apply the examples provided. Finally, having a basic grasp of version control concepts will enhance your ability to navigate through this guide effectively.

Basic Git Commands

In this section, you'll learn the fundamental Git commands that serve as the building blocks for efficiently managing and navigating your Git repositories.

Git is a distributed version control system that's essential for tracking changes in your codebase, collaborating with other developers, and maintaining the integrity of your project history. Understanding these basic commands is crucial for anyone looking to leverage the full power of Git in their development workflow.

We'll explore a variety of commands that cover key aspects of Git usage, such as initializing new repositories, committing changes, branching, and merging.

Each command is explained with a short sentence that describes its purpose along with its syntax, so you can effectively use it in real-world scenarios. Whether you're setting up a new project or working on an existing codebase, these commands will help you keep your work organized and maintain a seamless workflow.

git help

The git help command prints Git help information. It provides a quick reference to Git's basic usage and the most commonly used Git commands. This command is useful when you need a quick reminder of Git's functionality or want to explore available commands.

You can also use git help <command> to display help information for any specific Git command. For example, git help git prints the Git help specifically for the Git command itself.

These help commands are valuable resources for both beginners and experienced users to quickly access information about Git's features and usage.

git version

The git version command displays the version of Git installed on your system. This command is useful for verifying which version of Git you are currently using, which can be important for compatibility with certain features or when troubleshooting issues.

git init

The command git init is used to initialize a new Git repository in the current directory. This command creates a new subdirectory named .git that contains all the necessary metadata for the new repository. It's typically the first command you run when starting a new project that you want to manage with Git.

After running this command, you can begin tracking files and making commits in your new Git repository.

git clone <repository_url>

The git clone <repository_url> command creates a copy of a remote Git repository on your local machine. It downloads all the files, branches, and commit history, allowing you to start working with the project immediately.

git status

The git status command shows the current state of the Git repository's working directory and staging area. It displays information about which files have been modified, added, or deleted, and whether these changes are staged for the next commit.

The Working Directory and the Staging Area

The working directory and the staging area are fundamental concepts in Git that play crucial roles in the version control process.

The working directory is the environment where you actively make changes to your files, representing the current state of your project. It is essentially a sandbox where you can freely edit, delete, and create files as you develop your project. But these changes are local to your machine and not yet part of the version history.

On the other hand, the staging area, also known as the index, serves as an intermediary space between the working directory and the repository. It acts as a checkpoint where you can selectively organize changes before they are committed to the repository's history. This allows you to prepare a set of changes that are logically related, ensuring that each commit is meaningful and coherent.

The commands below will help you manage changes between the working directory and the staging area. They'll let you add files to the staging area, remove them, or modify the existing ones, giving you control over what will be included in the next commit.

By using these commands, you can ensure that only the intended updates are committed, making your project's history clear and organized. This process is essential for maintaining a clean and understandable history, as it allows you to track the evolution of your project with precision and clarity.

git checkout .

This command discards all changes in the working directory, reverting files to their last committed state. This command is useful for quickly undoing local modifications and restoring the working directory to a clean state.

git reset -p

This command allows you to interactively reset changes in the working directory. It provides a way to selectively undo modifications, giving you fine-grained control over which changes to keep or discard.

git add <file>

This command adds a specific file to the staging area in Git. This prepares the file for inclusion in the next commit, allowing you to selectively choose which changes to include in your version history.

git add -p

Allows you to interactively stage changes from your working directory by breaking them into chunks (hunks). This lets you review and selectively add parts of the changes to the index before committing.

git add -i

Enters the interactive mode of adding files. Provides a text-based interactive menu where you can select various actions to perform, such as staging individual changes, updating files, or viewing the status.

git rm <file>

Removes a file from the working directory and stages the removal.

git rm --cached <file>

Removes the specified file from the staging area (index) but leaves it intact in your working directory. This effectively un-tracks the file from version control.

git mv <old_path> <new_path>

This command is used to move or rename a file or directory within a Git repository. It automatically stages the change, making it ready for the next commit.

git commit -m "message"

This command is used to create a new commit in your Git repository. It saves the changes that have been staged (added to the index) along with a descriptive message. This message should briefly explain what changes were made in this commit.

Working with Branches

Git branches are parallel lines of development within a Git repository. They allow you to work on different features, bug fixes, or experiments independently from the main codebase.

Each branch can have its own commit history, and changes made in one branch do not affect others until they are merged. This helps you organize your work, and facilitates collaboration by enabling multiple developers to work on different aspects of a project simultaneously without interfering with each other's progress.

In this section we'll introduce commands that allow you to create, switch, list, rename, and delete branches in your Git repository. These commands help manage parallel lines of development, enabling you to work on different features or bug fixes independently. You'll also learn how to display commit histories and branch relationships, as well as manage remote branches.

git branch <branch_name>

Creates a new branch.

git checkout <branch_name>

Switches to the specified branch and updates the working directory.

git branch

Lists all branches.

git branch -d <branch_name>

Deletes a branch.

git push --delete <remote> <branch>

Deletes a remote branch.

git branch -m <old_name> <new_name>

Renames a branch.

git checkout -b <new_branch>

Creates and switches to a new branch named <new_branch>, based on the current branch.

git switch <branch>

Switches the working directory to the specified branch.

git show-branch <branch>

Displays a summary of the commit history and branch relationships for all or selected branches, showing where each branch diverged.

git show-branch --all

Same as above, but for all branches and their commits.

git branch -r

Lists all remote branches that your local repository is aware of.

git branch -a

Lists all branches in your repository, including both local and remote branches (the ones the local repository is aware of).

git branch --merged

Lists all branches that have been fully merged into the current branch, and can be safely deleted if no longer needed.

git branch --no-merged

Lists all branches that have not been fully merged into your current branch, showing branches with changes that haven't been integrated yet.

Merging in Git

The git merge command is used to combine the changes from one branch into another branch. It integrates the histories of both branches, creating a new commit that includes the changes from both sources.

This process allows multiple lines of development to be brought together, facilitating collaboration and ensuring that all updates are incorporated into the main project.

During a merge, conflicts may arise if changes overlap, requiring manual resolution to ensure a coherent final result.

git merge <branch>

Integrates the changes from the specified branch into your current branch, combining their histories.

git merge --no-ff <branch>

Merges the specified branch into your current branch, always creating a new merge commit even if a fast-forward merge is possible.

git merge --squash <branch>

Combines all the changes from the specified branch into a single commit, preparing the changes for a commit in the current branch without merging the branch’s history. This allows you to manually edit the commit message.

git merge --abort

Cancels an ongoing merge process and restores the state of your working directory and index to what it was before the merge started.

git merge -s ours <branch> or

git merge —-strategy=ours <branch>

These commands are functionally the same, but the second is the expanded (more explicit) version, while git merge -s ours <branch> is the shorthand version (which is commonly used). You'll see this a few times throughout this guide.

The git merge —-strategy=ours <branch> command (git merge -s ours <branch> for short) performs a merge using the "ours" strategy, which keeps the current branch's changes and discards changes from the specified branch. This effectively merges the histories without integrating the changes from the other branch.

git merge --strategy=theirs <branch>

Merges the specified branch into the current branch using the "theirs" strategy, which resolves all conflicts by favoring changes from the branch being merged. Note that the "theirs" strategy is not a built-in strategy and usually requires custom scripting or is used with tools to handle conflict resolution.

Git Remotes

Git remotes are references to remote repositories, which are versions of your project hosted on the internet or another network. They enable collaboration by allowing multiple users to share and sync changes with a central repository.

Common operations with remotes include git fetch to retrieve updates, git pull to fetch and merge changes, and git push to upload local commits to the remote repository.

Managing remotes involves adding, removing, and renaming remote connections, as well as configuring URLs for seamless collaboration.

git fetch

Fetches changes from a remote repository but does not merge them into your current branch.

git pull

Fetches changes from a remote repository and immediately merges them into your current branch.

git push

Uploads your local branch's changes to a remote repository.

git remote

Lists the names of remote repositories configured for your local repository.

git remote -v

Displays the URLs of the remote repositories associated with your local repository, showing both the fetched and pushed URLs.

git remote add <name> <url>

Adds a new remote repository with the specified name and URL to your local repository configuration.

git remote remove <name> or

git remote rm <name>

Deletes the specified remote repository connection from your local git configuration. git remote rm <name> is the shorthand version of the command.

git remote rename <old_name> <new_name>

Changes the name of an existing remote repository connection in your local Git configuration

git remote set-url <name> <newurl>

Changes the URL of an existing remote repository connection in your local Git configuration.

git fetch <remote>

Retrieves the latest changes from the specified remote repository, updating your local copy of the remote branches without merging them into your local branches.

git pull <remote>

Fetches changes from the specified remote repository and merges them into your current branch.

git remote update

Fetches updates for all remotes tracked by the repository.

git push <remote> <branch>

Uploads the specified branch from your local repository to the given remote repository.

git push <remote> --delete <branch>

Removes the specified branch from the remote repository.

git remote show <remote>

Displays detailed information about the specified remote repository, including its URL, fetch and push configurations, and the branches it tracks.

git ls-remote <repository>

Lists references (such as branches and tags) and their commit IDs from the specified remote repository. This command allows you to view the branches and tags available in a remote repository without cloning it.

git push origin <branch> --set-upstream

Pushes the local branch <branch> to the remote repository origin and sets up the local branch to track the remote branch. This lets future git push and git pull commands default to this remote branch.

git remote add upstream <repository>

Adds a new remote named upstream to your local repository, pointing to the specified <repository>. This is commonly used to track the original repository from which you forked, while origin typically refers to your own fork.

git fetch upstream

Retrieves updates from the upstream remote repository, updating your local references to the branches and tags from that remote without modifying your working directory or merging changes.

git pull upstream <branch>

Fetches updates from the <branch> of the upstream remote repository and merges those changes into your current branch. This is often used to integrate changes from the original repository into your own local branch.

git push origin <branch>

Uploads the local branch <branch> to the origin remote repository, making your branch and its commits available on the remote.

Amending Commits

Amending Git commits allows you to modify the most recent commit, typically to correct or update its contents or message. You can do this using the git commit --amend command, which opens the commit in your default text editor for changes.

Amending is particularly useful for fixing small mistakes or adding forgotten changes without creating a new commit, resulting in a cleaner and more accurate commit history.

git commit --amend

Modifies the most recent commit, combining staged changes.

git commit --amend -m "new message"

Amends the commit message of the most recent commit.

git commit --fixup=HEAD

Creates a new commit with the --fixup option that is intended to correct or amend the most recent commit (HEAD). The new commit is marked with a fixup! prefix in the commit message and will be used to automatically fix or amend the specified commit during an interactive rebase.

Stashing in Git

Git stashing is a feature that allows you to temporarily save changes in your working directory that are not yet ready to be committed.

By using the git stash command, you can set aside these changes and revert your working directory to a clean state, enabling you to switch branches or perform other tasks without losing progress. Later, you can reapply the stashed changes with git stash apply or git stash pop, allowing you to continue where you left off.

This functionality is especially useful for managing work in progress when you need to address an urgent issue or experiment with a different code path.

git stash

Temporarily saves your uncommitted changes, allowing you to switch branches or perform other operations without committing incomplete work.

There's an older version, git stash save, that allows you to specify a custom message. But it's largely been deprecated in favor of the simpler git stash.

git stash -m "message"

Same as above, but stores changes with a message. It also has an older version, git stash save "message", but git stash -m "message" is preferred for versions of Git 2.13 and newer.

git stash show

Displays a summary of the changes in the most recent stash entry, showing which files were modified.

git stash list

Shows all the stashed changes in your repository, displaying them in a numbered list.

git stash pop

Applies the most recent stash and then immediately removes it from the stash list.

git stash drop

Removes the most recent stash entry from the stash list without applying it to your working directory.

git stash apply

Reapplies the most recently stashed changes to your working directory without removing them from the stash list.

git stash clear

Clears and removes all stashed entries, permanently deleting all saved changes in your stash.

git stash branch <branch>

Creates a new branch named <branch> from the commit where you were before stashing your changes. Then it applies the stashed changes to that new branch.

This command effectively allows you to continue working on your stashed changes in a separate branch, preserving the original context and changes.

Git Tagging

Git tagging is a feature that allows you to mark specific points in your repository's history as important with a meaningful name, often used for releases or significant milestones.

Unlike branches, tags are typically immutable and do not change, serving as a permanent reference to a particular commit.

There are two types of tags in Git: lightweight tags, which are simple pointers to a commit, and annotated tags, which store additional metadata like the tagger's name, email, date, and a message.

Tags can be easily created, listed, pushed to remote repositories, and deleted, providing a convenient way to manage and reference key points in your project's development timeline.

git tag <tag_name>

Creates a new tag with the specified name pointing to the current commit (typically used to mark specific points in the commit history, like releases).

git tag -a <tag_name> -m "message"

Creates an annotated tag with the specified name and message, which includes additional metadata like the tagger's name, email, and date, and points to the current commit.

git tag -d <tag_name>

Deletes the specified tag from your local repository.

git tag -f <tag> <commit>

Forces a tag to point to a different commit.

git show <tag_name>

Displays detailed information about the specified tag, including the commit it points to and any associated tag messages or annotations.

git push origin <tag_name>

Uploads the specified tag to the remote repository, making it available to others.

git push origin --tags

Pushes all local tags to the remote repository, ensuring that all tags are synchronized with the remote.

git push --follow-tags

Pushes both commits and tags.

git fetch --tags

Retrieves all tags from the default remote repository and updates your local repository with them, without affecting your current branches.

Reverting Changes in Git

Reverting changes in Git involves undoing modifications made to a repository's history. You can do this using several commands, such as git revert. It creates a new commit that negates the changes of a specified previous commit, effectively reversing its effects while preserving the commit history.

Another method is using git reset, which changes the current HEAD to a specified commit and can update the staging area and working directory depending on the chosen options (--soft, --mixed, or --hard).

You can also use git checkout to discard changes in the working directory, reverting files to their state in the last commit.

These tools provide flexibility in managing and correcting changes, ensuring the repository remains accurate and clean.

git checkout -- <file>

Discards changes in the specified file from the working directory, reverting it to the state of the last commit and effectively undoing any modifications that haven't been staged.

git revert <commit>

Creates a new commit that undoes the changes in the specified commit, effectively reversing its effects while preserving the history.

git revert -n <commit>

Reverts a commit but does not commit the result.

git reset

Resets the current HEAD to the specified state, and optionally updates the staging area and working directory, depending on the options used (--soft, --mixed, or --hard).

git reset --soft <commit>

Moves HEAD to the specified commit, while keeping the index (staging area) and working directory unchanged, so all changes after the specified commit remain staged for committing. This is useful when you want to undo commits but keep the changes ready to be committed again.

git reset --mixed <commit>

Moves HEAD to the specified commit and updates the index (staging area) to match that commit. But it leaves the working directory unchanged, so changes after the specified commit are kept but are untracked.

git reset --hard <commit>

Moves HEAD to the specified commit and updates both the index (staging area) and working directory to match that commit. It discards all changes and untracked files after the specified commit.

Viewing History Logs

Git history refers to the record of all changes made to a repository over time. It includes a chronological sequence of commits, each representing a snapshot of the repository at a specific point.

This history allows you to track modifications, understand the evolution of the codebase, and collaborate effectively by providing a detailed log of who made changes, when, and why.

Tools like git log help you navigate this history, offering insights into the development process and aiding in debugging and project management.

git log

Displays the commits log.

git log --oneline

Displays a summary of commits with one line each.

git log --graph

Shows a graphical representation of the commit history.

git log --stat

Displays file statistics along with the commit history.

git log --pretty=format:"%h %s"

Formats the log output according to the specified format.

git log --pretty=format:"%h - %an, %ar : %s"

Provides a more human-readable format for logs.

git log --author=<author>

Shows commits made by the specified author.

git log --before=<date>

Shows commits made before the specified date.

git log --after=<date>

Shows commits made after the specified date (same as git log --since=<date>)

git log --cherry-pick

Omits commits that are equivalent between two branches.

git log --follow <file>

Shows commits for a file, including renames.

git log --show-signature

Displays GPG signature information for commits.

git shortlog

Summarizes git log output by author.

git shortlog -sn

Summarizes git log output by author, with commit counts.

git log --simplify-by-decoration

Shows only commits that are referenced by tags or branches.

git log --no-merges

Omits merge commits from the log.

git whatchanged

Lists commit data in a format similar to a commit log.

git diff-tree --pretty --name-only --root <commit>

Shows detailed information for a commit tree.

git log --first-parent

Only shows commits of the current branch and excludes those merged from other branches.

Git Diffs

Git diffs are a feature in Git that allows you to see the differences between various states in your repository. This can include differences between your working directory and the staging area, between the staging area and the last commit, or between any two commits or branches.

By displaying line-by-line changes in files, diffs help you review modifications before committing, merging, or applying changes, thus ensuring accuracy and consistency in your codebase.

git diff

Shows the differences between various states in your repository, such as between your working directory and the index (staging area), between the index and the last commit, or between two commits. It displays line-by-line changes in files, helping you review modifications before committing or merging.

git diff --stat

Shows a summary of changes between your working directory and the index (staging area), helping you see what files have been modified and how many lines have been added or removed.

git diff --stat <commit>

Views changes between a commit and the working directory.

git diff --stat <commit1> <commit2>

Provides a summary of changes between two commits, showing which files were altered and the extent of changes between them.

git diff --stat <branch1> <branch2>

Summarizes the differences between the two branches, indicating the files changed and the magnitude of changes.

git diff --name-only <commit>

Shows only the names of files that changed in the specified commit.

git diff --cached

Shows the differences between the staged changes (index) and the last commit, helping you review what will be included in the next commit.

git diff HEAD

Shows the differences between the working directory and the latest commit (HEAD), allowing you to see what changes have been made since the last commit.

git diff <branch1> <branch2>

Shows the differences between the tips of two branches, highlighting the changes between the commits at the end of each branch.

git difftool

Launches a diff tool to compare changes.

git difftool <commit1> <commit2>

Uses the diff tool to show the differences between two specified commits.

git difftool <branch1> <branch2>

Opens the diff tool to compare changes between two branches.

git cherry <branch>

Compares the commits in your current branch against another branch and shows which commits are unique to each branch. It is commonly used to identify which commits in one branch have not been applied to another branch.

Git Flow

Git Flow is a branching model for Git that provides a robust framework for managing larger projects. It defines a strict branching strategy designed around the project release cycle, with two primary branches (main and develop) and supporting branches for features, releases, and hotfixes.

This model helps in organizing work, ensuring a clean and manageable history, and facilitating collaboration by clearly defining roles and processes for different types of development work.

git flow init

Initializes a repository for a git-flow branching model.

git flow feature start <feature>

Starts a new feature branch in git-flow.

git flow feature finish <feature>

Finishes a feature branch in git-flow.

Exploring Git References

Git references, often referred to as refs, are pointers to specific commits or objects within a Git repository. These can include branches, tags, and other references like HEAD, which points to the current commit checked out in your working directory.

References are used to keep track of the structure and history of the repository. They help Git efficiently manage and navigate different points in the project's timeline.

Refs also provide a way to name and refer to particular commits, making it easier to work with and manipulate the repository's history.

git show-ref --heads

Lists references to all heads (branches).

git show-ref --tags

Lists references to all tags.

How to Configure Git

Git configuration involves setting up various options and preferences that control the behavior of your Git environment. This can include specifying your username and email, setting up default text editors, creating aliases for commonly used commands, and configuring global ignore files.

You can apply configuration settings at different levels: global (affecting all repositories on your system), local (affecting a single repository), and system-wide. These settings ensure a customized and consistent user experience, streamline workflows, and enhance the overall efficiency of version control operations.

git config --global user.name "Your Name"

Sets the user name on a global level.

git config --global user.email "your_email@example.com"

Sets the user email on a global level.

git config --global core.editor <editor>

Sets the default text editor.

git config --global core.excludesfile <file>

Sets the global ignore file.

git config --list

Lists all the configuration settings.

git config --list --show-origin

Lists all config variables, showing their origins.

git config <key>

Retrieves the value for the specified key.

git config --get <key>

Retrieves the value for the specified configuration key.

git config --unset <key>

Removes the specified configuration key.

git config --global --unset <key>

Removes the specified configuration key globally.

Git Security

Git GPG security involves using GNU Privacy Guard (GPG) to sign commits and tags, ensuring their authenticity and integrity. By configuring a GPG key and enabling automatic signing, you can verify that commits and tags were created by a trusted source. This helps prevent tampering and ensures the integrity of the repository's history.

This practice enhances security by providing cryptographic assurance that the changes come from a legitimate contributor.

git config --global user.signingKey <key>

Configures the GPG key for signing commits and tags.

git config --global commit.gpgSign true

Automatically signs all commits with GPG.

How to Set Aliases in Git

Git aliases are custom shortcuts that you can create to simplify and speed up your workflow by mapping longer Git commands to shorter, more memorable names.

By configuring aliases in your Git settings, you can quickly execute frequently used commands with less typing. This not only enhances productivity but also reduces the likelihood of errors.

For example, you can set an alias like git st to replace git status, or git co to replace git checkout.

You can define aliases globally to apply across all repositories or locally for individual projects, providing flexibility in how you streamline your Git operations.

git config --global alias.ci commit

Sets git ci as an alias for git commit.

git config --global alias.st status

Sets git st as an alias for git status.

git config --global alias.co checkout

Sets git co as an alias for git checkout.

git config --global alias.br branch

Sets git br as an alias for git branch.

git config --global alias.graph "log --graph --all --oneline --decorate"

Creates an alias for a detailed graph of the repository history.

Rebasing in Git

Git rebasing re-applies your changes on top of another branch's history, creating a cleaner and more linear project history.

In practice, this helps integrate updates smoothly by avoiding unnecessary merge commits, ensuring that the commit sequence is straightforward, and making it easier to understand the evolution of the project.

git rebase <branch>

The git rebase command is used to re-apply commits on top of another base tip. It allows you to move or combine a sequence of commits to a new base commit. This is commonly used to:

1. Keep a linear project history.

2. Integrate changes from one branch into another.

3. Update a feature branch with the latest changes from the main branch.

The basic usage is git rebase <branch>, which will rebase the current branch onto the specified branch.

git rebase --interactive <branch>

Starts an interactive rebase session, allowing you to modify commits starting from <base> up to the current HEAD. This lets you reorder, squash, edit, or delete commits, providing a way to clean up and refine commit history before pushing changes. Shorter version: git rebase -i <branch>

git rebase --continue

Continues the rebase process after resolving conflicts.

git rebase --abort

Aborts the rebase process and returns to the original branch.

git fetch --rebase

Fetches from the remote repository and rebases local changes.

What is Cherry-Picking?

Git cherry-picking is a process that allows you to apply the changes introduced by a specific commit from one branch into another branch. This is particularly useful when you want to selectively incorporate individual changes from different branches without merging the entire branch.

By using the git cherry-pick command, you can isolate and integrate only the desired commits, ensuring that specific modifications are included in your current branch while avoiding potential conflicts and unwanted changes from other parts of the branch.

git cherry-pick <commit>

Applies the changes introduced by an existing commit.

git cherry-pick --continue

Continues cherry-picking after resolving conflicts.

git cherry-pick --abort

Aborts the cherry-pick process.

git cherry-pick --no-commit <commit>

Cherry-picks a commit without automatically committing and allows further changes. Shorter version: git cherry-pick -n <commit>

Patching in Git

Git patching is a method used to apply changes from one repository to another or from one branch to another within the same repository. It involves creating patch files, which are text files representing differences between commits or branches. These patch files can then be applied to a repository using commands like git apply or git am, allowing changes to be transferred and integrated without directly merging branches.

Patching is particularly useful for sharing specific changes or updates across different codebases, ensuring that only the intended modifications are applied.

git apply <patch_file>

Applies changes to the working directory from a patch file.

git apply --check

Checks if patches can be applied cleanly.

git format-patch <since_commit>

Creates patch files for each commit since the specified commit.

git am <patch_file>

Applies patches from a mailbox.

git am --continue

Continues applying patches after resolving conflicts.

git am --abort

Aborts the patch application process.

git diff > <file.patch>

Creates a patch file from differences.

Relative Dates in Git

Git relative dates allow users to refer to specific points in the repository's history using human-readable time expressions. For instance, commands like main@{1.week.ago} or @{3.days.ago} enable you to access the state of a branch or view changes made since a certain time period relative to the current date.

This feature simplifies navigating the repository's timeline by using intuitive terms like "yesterday," "2 weeks ago," or specific dates, making it easier to track and manage the evolution of the codebase without needing to remember exact commit hashes or timestamps.

git show main@{1.week.ago}

Lets you see the state of your main branch one week ago.

git diff @{3.days.ago}

Shows what changes you've made in the last 3 days.

git checkout main@{2.weeks.ago}

Checks out your repository as it was 2 weeks ago.

git log @{1.month.ago}..HEAD

Shows you the log of commits from 1 month ago until now.

@{2024-06-01}

@{yesterday}

@{"1 week 2 days ago"}

Other usage examples.

Git Blame

Git blaming is a feature in Git that identifies the last modification made to each line of a file, attributing changes to specific commits and authors. You can do this using the git blame command, which provides a detailed annotation of the file, showing who made changes and when they were made.

This tool is particularly useful for tracking the history of a file, understanding the evolution of the code, and identifying the source of bugs or changes.

By pinpointing the exact commit and author responsible for each line, developers can gain insights into the development process and facilitate better collaboration and accountability within a team.

git blame <file>

Shows the last modification for each line of a file.

git blame <file> -L <start>,<end>

Limits the blame output to the specified line range.

git blame <file> <commit>

Shows the blame information up to the specified commit.

git blame <file> -C -C

Shows which revisions and authors last modified each line of a file, with copying detection.

The -C option detects lines moved or copied within the same file. Using it once (-C) detects lines moved or copied within the same file. Using the -C option twice (-C -C) makes Git inspect unmodified files as candidates for the source of copy. This means it will try to find the origin of copied lines not just in the same file but in other files as well.

git blame <file> --reverse

Works backwards, showing who last altered each line in the specified file.

git blame <file> --first-parent

Shows who most recently modified each line in a file, following only the first parent commit for merge changes.

Archiving in Git

Git archiving is a feature that allows you to create archive files, such as .tar or .zip, containing the contents of a specific commit, branch, or tag. This is useful for packaging a snapshot of your repository at a specific point in time, enabling you to distribute or backup the repository's state without including the entire Git history.

The git archive command is typically used for this purpose, providing a convenient way to export the current state of the project into a portable format.

git archive <format> <tree-ish>

Creates an archive file (for example, a .tar or .zip file) containing the contents of the specified tree-ish (like a commit, branch, or tag) in the given format. For example:

• git archive --format=tar HEAD creates a .tar archive of the current commit (HEAD).

• git archive --format=zip v1.0 creates a .zip archive of the files in the v1.0 tag.

This command is useful for packaging a snapshot of your repository at a specific point in time.

How to Track Files in Git

Git tracking refers to the process of monitoring and managing the files in a repository.

The command git ls-files lists all files that are being tracked by Git, providing a clear view of the files that are currently under version control. On the other hand, git ls-tree <branch> displays the contents of a tree object for a specified branch, showing the structure and files at that point in the repository.

Together, these commands help developers understand which files are included in the repository and how they are organized, ensuring efficient tracking and management of the project's codebase.

git ls-files

Lists all tracked files.

git ls-tree <branch>

Lists the contents of a tree object.

Index Manipulation in Git

Git index manipulation involves managing the staging area (also known as the index) where changes are prepared before committing. This can include marking files as "assume unchanged" to temporarily ignore changes, or resetting these markings to track changes again.

Index manipulation commands, such as git update-index, allow you to control which files are included in the next commit, providing flexibility in handling changes and optimizing the workflow for specific tasks.

git update-index --assume-unchanged <file>

Marks a file as assume unchanged.

git update-index --no-assume-unchanged <file>

Unmarks a file as assume unchanged.

Squashing in Git

Git squashing is the process of combining multiple commits into a single commit. Devs often do this to clean up the commit history before merging changes into a main branch, making the history more concise and easier to read.

Squashing can be performed using the interactive rebase command (git rebase -i), which lets you selectively merge, reorder, or edit commits. By squashing commits, you can consolidate redundant or minor changes, presenting a clearer narrative of the development process.

git rebase -i HEAD~<n>

Squashes commits interactively.

Data Integrity in Git

Git data integrity refers to the mechanisms and processes Git employs to ensure the accuracy and consistency of data within a repository.

Git uses cryptographic hashes (SHA-1 or SHA-256) to uniquely identify objects such as commits, trees, and blobs. This hashing not only provides a unique identifier for each object but also ensures that any modification to the object's content will result in a different hash, thus detecting any corruption or tampering.

You can use commands like git fsck to verify the connectivity and validity of objects in the database, ensuring the overall health and integrity of the repository.

git fsck

Verifies the connectivity and validity of objects in the database.

git fsck --unreachable

Finds objects in the repository that are not reachable from any reference.

git prune

Removes unreachable objects.

git gc

Runs a garbage collection process.

Git garbage collection is a maintenance process that cleans up and optimizes the repository by removing unnecessary files and compressing file revisions to save space. This process, triggered by the git gc command, consolidates and deletes unreachable objects, such as orphaned commits and unreferenced blobs, ensuring the repository remains efficient and performant.

Regular garbage collection helps manage storage effectively and keeps the repository's structure organized.

Cleaning Up in Git

Cleaning up in Git involves removing unnecessary files, references, and branches that are no longer needed. This helps to keep your repository organized and efficient.

Regular cleanup activities, such as pruning remote-tracking branches, deleting untracked files, and removing stale references, ensure that your repository remains manageable and free from clutter.

In practice, these actions can improve performance, reduce storage requirements, and make it easier to navigate and work within your project.

git fetch --prune

Removes references that no longer exist on the remote.

git remote prune <name>

Prunes all stale remote-tracking branches.

git fetch origin --prune

Cleans up outdated references from the remote repository.

git clean -f

Removes untracked files from the working directory, forcing the deletion of files not being tracked by Git.

git clean -fd

Removes untracked files and directories from the working directory, including any files and directories not tracked by Git.

git clean -i

Enters interactive mode for cleaning untracked files.

git clean -X

Removes only ignored files from the working directory.

Git Subtree

Git subtree is a mechanism for managing and integrating subprojects into a main repository. Unlike submodules, which treat the subproject as a separate entity with its own repository, subtrees allow you to include the contents of another repository directly within a subdirectory of your main repository.

This approach simplifies the workflow by eliminating the need for multiple repositories and enabling seamless integration, merging, and pulling of updates from the subproject. Subtrees provide a flexible and convenient way to manage dependencies and collaborate on projects that require incorporating external codebases.

git subtree add --prefix=<dir> <repository> <branch>

Adds a repository as a subtree.

git subtree merge --prefix=<dir> <branch>

Merges a subtree.

git subtree pull --prefix=<dir> <repository> <branch>

Pulls in new changes from the subtree's repository.

How to Search in Git

git grep is a powerful search command in Git that allows users to search for specific strings or patterns within the files of a repository. It searches through the working directory and the index, providing a quick and efficient way to locate occurrences of a specified pattern across multiple files.

This command is particularly useful for developers looking to find instances of code, comments, or text within a project, enabling them to navigate and understand large codebases with ease. With various options and flags, git grep lets you perform targeted searches, making it an essential tool for code analysis and maintenance.

git grep <pattern>

Searches for a string in the working directory and the index.

git grep -e <pattern>

Searches for a specific pattern.

Bisecting in Git

Git bisecting is a powerful debugging tool that helps identify the specific commit that introduced a bug or issue in a project. By performing a binary search through the commit history, git bisect efficiently narrows down the range of potential problem commits.

The process involves marking a known good commit and a known bad commit, and then repeatedly testing intermediate commits to determine whether they are good or bad.

This iterative approach quickly isolates the faulty commit, allowing developers to pinpoint the exact change that caused the problem. This facilitates faster and more accurate debugging.

git bisect start

Starts a bisect session.

git bisect bad

Marks the current version as bad.

git bisect good <commit>

Marks the specified commit as good.

git bisect reset

Ends a bisect session and returns to the original branch.

git bisect visualize

Launches a visual tool to assist with bisecting.

Git Attributes

Git attributes are settings that define how Git should handle specific files or paths within a repository. These attributes are defined in a file named .gitattributes, and they can control various behaviors such as text encoding, line-ending normalization, merge strategies, and diff algorithms.

By setting attributes, you can ensure consistent behavior across different environments and collaborators, making it easier to manage files with special requirements or complexities.

For example, you can mark certain files as binary to prevent Git from attempting to merge them, or specify custom diff drivers for more meaningful comparisons.

git check-attr <attribute> -- <file>

Shows the value of a specific attribute for the given file as defined in the .gitattributes configuration, helping you understand how Git is treating the file with respect to attributes like text encoding, merge behavior, or diff handling.

Git Checkout

git checkout is a versatile command in Git used to switch between different branches, tags, or commits within a repository. By updating the working directory and index to match the specified branch or commit, it allows you to view or work with the state of the repository at that point.

You can also use git checkout to create new branches, restore specific files from a commit, or even start a new branch with no history using the --orphan option. This command is essential for navigating and managing different versions of a project's codebase.

git checkout <commit>

Updates the working directory and index to match the specified commit, allowing you to view or work with the state of the repository at that commit. Just keep in mind that this leaves you in a "detached HEAD" state, meaning you're not on any branch.

git checkout -b <branch> <commit>

Creates a new branch named <branch> starting from the specified commit and switches to that branch, allowing you to begin working from that point in the commit history.

git checkout <commit> -- <file>

Restores the specified file from a specific commit into your working directory, replacing the current version of the file with the version from that commit without changing the commit history or index.

git checkout --orphan <new_branch>

Creates a new branch named <new_branch> with no commit history, effectively starting a new branch that begins with a clean working directory and index, as if it were a new repository.

Git Reflog

Git reflog is a powerful tool that records all changes made to the tips of branches and the HEAD reference in a Git repository. This includes actions such as commits, checkouts, merges, and resets.

By maintaining a history of these changes, reflog allows users to track recent modifications and recover lost commits, even if they are not part of the current branch history. It provides a way to navigate through the repository's state changes, making it an invaluable resource for debugging and undoing mistakes.

git reflog

Displays a log of all the changes to the HEAD reference and branch tips, including commits, checkouts, merges, and resets, allowing you to recover lost commits or track recent changes to the repository's state.

git reflog show <ref>

Displays the reflog for the specified reference (<ref>), showing a log of changes to that reference, including updates to HEAD or branch tips, along with associated commit messages and timestamps.

How to Handle Untracked Files in Git

git clean

git clean removes untracked files and directories from the working directory. By default, it only shows what would be removed without actually deleting anything.

To perform the actual cleanup, you need to use additional flags:

• git clean -f: Removes untracked files.

• git clean -fd: Removes untracked files and directories.

• git clean -fx: Removes untracked files, including those ignored by .gitignore.

• git clean -n: Shows which files would be removed without actually deleting them.

Force Pushing in Git

git push --force

Forces a push of your local branch to the remote repository, even if it results in a non-fast-forward merge. It overwrites the remote branch with your local changes.

This can be necessary when you have rewritten history (for example, with a rebase) and need to update the remote branch to match your local branch. But it can also potentially overwrite others' changes – so use it with caution.

Git Fetching and Pulling

git fetch --all

Retrieves updates from all remote repositories configured for your local repository, fetching changes from all branches and tags without modifying your local branches.

git pull --rebase

Fetches changes from the remote repository and rebases your local commits on top of the updated remote branch, rather than merging them. This keeps the commit history linear and avoids unnecessary merge commits.

How to Handle Merge Conflicts in Git

Handling merge conflicts in Git is an essential skill for collaborating on projects with multiple contributors.

Merge conflicts occur when changes in different branches or commits overlap or contradict each other, preventing an automatic merge. Resolving these conflicts involves reviewing and manually reconciling the differences to ensure that the final code integrates contributions from all parties accurately.

In practice, effectively managing merge conflicts helps maintain code integrity and facilitates smooth collaboration by ensuring that everyone's changes are correctly incorporated into the project's history.

git mergetool

This launches a merge tool to help you resolve conflicts that arise during a merge or rebase. It opens a graphical interface or a text-based tool configured in your Git settings, allowing you to manually resolve conflicts and finalize the merge.

git rerere

rerere stands for "reuse recorded resolution" and is a feature that helps automatically resolve conflicts in future merges or rebases by reusing conflict resolutions you've previously recorded.

Once enabled, Git records how you resolved conflicts. If the same conflicts arise again, it can apply the same resolutions automatically.

Working Trees in Git

Working trees in Git allow you to have multiple working directories associated with a single repository. This is particularly useful for working on multiple branches simultaneously without the need to constantly switch branches in the same directory.

By using working trees, you can easily manage different features, bug fixes, or experiments in isolated environments, improving workflow efficiency and reducing the risk of conflicts.

git worktree add ../new-branch feature-branch

Creates a new working tree in a directory named "new-branch" based on the "feature-branch".

git worktree list

Lists all working trees associated with the current repository, showing their paths and the branches they are checked out to.

git worktree remove <path>

Removes the specified working tree at the given <path>, deleting the working directory and detaching the branch.

git worktree prune

Removes references to nonexistent working trees, cleaning up the working tree list.

git worktree lock <path>

Locks the specified working tree at the given <path>, preventing it from being pruned.

git worktree unlock <path>

Unlocks the specified working tree at the given <path>, allowing it to be pruned if necessary.

Submodules in Git

Submodules in Git are a way to include and manage external repositories within your own repository. They are particularly useful for reusing code across multiple projects, maintaining dependencies, or integrating third-party libraries.

By using submodules, you can keep your main repository clean and modular, while still ensuring that all necessary components are included and version-controlled.

git submodule init

Initializes submodules in your repository. This command sets up the configuration necessary for the submodules, but doesn't actually clone them.

git submodule update

Clones and checks out the submodules into the specified paths. This is typically run after git submodule init.

git submodule add <repository> <path>

Adds a new submodule to your repository at the specified path, linking it to the specified repository.

git submodule status

Displays the status of all submodules, showing their commit hashes and whether they are up-to-date, modified, or uninitialized.

git submodule foreach <command>

Runs the specified command in each submodule. This is useful for performing batch operations across all submodules.

git submodule sync

Synchronizes the submodule URLs in your configuration file with those in the .gitmodules file, ensuring they are up-to-date.

git submodule deinit <path>

Unregisters the specified submodule, removing its configuration. This doesn't delete the submodule's working directory.

git submodule update --remote

Fetches and updates the submodules to the latest commit from their remote repositories.

git submodule set-url <path> <newurl>

Changes the URL of the specified submodule to the new URL.

git submodule absorbgitdirs

Absorbs the submodule's Git directory into the superproject to simplify the structure.

Thank you for reading! I hope this cheatsheet helps you work more easily in Git.

Like many beginners, I started researching hosting platforms, only to find out about the cost of domains and hosting. That's when I discovered Git and GitHub, realizing I could share my projects without spending a dime.

If you're in the same boat, unsure about Git and GitHub and how to share your projects, this article is for you. It's the guide I wish I had seven years ago.

To demonstrate the power of Git and GitHub, we'll be using a real-world project as an example. Let's take the "IP Address Tracker application" project from this freeCodeCamp tutorial. You can download the source code for the project here.

If you've followed the tutorial and built the project, or if you have a project you'd like to share, this article is for you. We'll walk you through the steps to host your project on GitHub, making it accessible to the world.

Table of Contents

1. Audience

2. Prerequisite Knowledge

3. Getting Started With Git and GitHub

   1. What is Git?

   2. What is GitHub?

4. How to Set Up Git and GitHub

   1. How to Install Git on Windows

   2. How to Install Git on macOS

   3. How to Install Git on Linux

   4. How to Create a GitHub Account

   5. How to Configure Git

5. How to Initialize a Git Repository

   1. Step 1: Download and Open Your Project

   2. Step 2: Open the Project in VS Code

   3. Step 3: Open the Terminal in VS Code

   4. Step 4: Initialize a Git Repository

6. How to Track Changes with Git

   1. Preparing Changes with git add

      1. Adding Individual Files

      2. Adding All Changes at Once

   2. Saving Changes with git commit

7. How to Push Your Project to GitHub

   1. Step 1: Create a New Repository on GitHub

   2. Step 2: Link Your Local Repository to GitHub

   3. Step 3: Push Your Local Changes to GitHub

   4. Step 4: Verify Your Repository on GitHub

8. How to Host Your Project on GitHub Pages

   1. What are GitHub Pages?

   2. How to Enable GitHub Pages

   3. How to Get Your GitHub Pages URL

   4. How to Update Your GitHub Pages Site

9. Conclusion

Audience

This guide is for beginner developers who have started learning HTML, CSS, and JavaScript and want to learn how to share their projects using Git and GitHub.

Prerequisite Knowledge

Before diving in, ensure you are familiar with:

• Basic command-line operations.

• HTML, CSS, and JavaScript fundamentals.

• A text editor like VS Code.

Getting Started With Git and GitHub

I am not going to try to bore you with the differences between Git and GitHub. I am sure there are tons of resources in the world wide web already covering that but from a beginner's point of view, here is what they are:

What is Git?

Git is a tool that helps you keep track of all the changes you make in your project's code. Imagine building a website about cats. If you change the website's title from "Cat Facts" to "All About Cats," Git will remember the change. If you later decide that you prefer "Cat Facts," Git lets you go back to that version easily.

It's like having a record of every edit, addition, and deletion you make to your project, so you can always revisit previous versions and make changes with confidence.

What is GitHub?

GitHub is like a cloud-based scrapbook for your code. It's an online record where you save every edit, addition, and deletion you make to your project, so you can access it from anywhere and share it with others.

Imagine having a digital filing cabinet where you can store and manage different versions of your website. You can invite friends to see and even help you with your project, making it easy to collaborate. GitHub tracks changes and keeps everything organized, so if something goes wrong, you can always go back to a previous version.

How to Set Up Git and GitHub

Now that we know what Git and GitHub are, let's get them set up on your computer. Follow these step-by-step instructions:

How to Install Git on Windows

You can download the Git installer here.

Run the installer and follow the setup instructions, keeping the default settings.

How to Install Git on macOS

Open the Terminal on your Mac. You can find it in Applications > Utilities or use Spotlight to search for it.

Install Git using Homebrew by copying and pasting the following commands:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install git

Output:

==> Downloading https://github.com/Homebrew/brew/tarballs/...
==> Installing git
==> Pouring git-2.43.0.mojave.bottle.tar.gz
🍺  /usr/local/Cellar/git/2.30.1: 1,434 files, 43.8MB

How to Install Git on Linux

Open Terminal on your Linux machine. Then use your distribution's package manager to install Git.

For example, on Ubuntu, copy and paste the following commands:

sudo apt-get update
sudo apt-get install git

Output:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
git-man liberror-perl
Suggested packages:
git-daemon-run git-daemon-sysvinit git-doc git-el git-email git-gui gitk
gitweb git-mediawiki git-arch git-cvs git-svn git-hg
The following NEW packages will be installed:
git git-man liberror-perl
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 7,841 kB of archives.
After this operation, 43.8 MB of additional disk space will be used.

To verify the installation, open Terminal (if it's not already open) and type the following command to verify the installation:

git --version

Output:

git version 2.43.0

You should see the installed Git version displayed.

How to Create a GitHub Account

• Go to GitHub and click on "Sign up."

• Follow the instructions to create your account, choose a username and password, and verify your email.

• Once your account is set up, customize your profile with a bio, profile picture, and links to your personal website or social media.

How to Configure Git

Open Terminal and configure Git with the same username and email as your GitHub account:

git config --global user.name "Your GitHub Username"
git config --global user.email "your.email@example.com"

No output will be displayed, but Git will store your credentials for future use.

How to Initialize a Git Repository

Now that you have Git and GitHub set up, let's start by initializing Git in a project. You can use any project of your choice or follow along with our example using the "IP Address Tracker" project.

Step 1: Download and Open Your Project

Download the source code for your chosen project or use the "IP Address Tracker" project from this link. Extract the downloaded ZIP file to a location on your computer. This will provide a concrete example to demonstrate Git concepts.

Step 2: Open the Project in VS Code

Open Visual Studio Code and click on "File" > "Open Folder" to select the folder where you extracted the project.

Step 3: Open the Terminal in VS Code

Click on "Terminal" > "New Terminal" to open the terminal in VS Code, where we'll interact with Git using commands.

Step 4: Initialize a Git Repository

Initialize a Git repository by running the following command:

git init

Output:

Initialized empty Git repository in /Users/spruceemmanuel/Documents/IP Address Tracker/.git/

This command creates a new hidden folder called .git in your project folder, which tracks changes to our project files. When you run git init, Git sets up the necessary files and directories to start versioning our project. This includes:

• A .git folder that stores all the metadata for your repository

• A main branch, which is the default branch for your repository

• A HEAD pointer, which points to the current branch (in this case, main).

By initializing a Git repository, you're telling Git to start tracking changes to your project files. This allows you to version your code, collaborate with others, and maintain a record of changes.

How to Track Changes with Git

Now that we’ve set up Git, it’s ready to keep track of changes in our project.

VSCode source control

Git notices change in our files, but before we can save these changes, we need to tell Git to do so.

Preparing Changes with git add

To get our changes ready to save, we use the git add command. Here’s how it works:

Adding Individual Files

If you want to add specific files, like index.html, script.js, or styles.css, you can use git add followed by the file name. For example:

git add index.html

Adding All Changes at Once

If you want to add all modified files in the project to the staging area, use:

git add .

Saving Changes with git commit

Once we’ve used git add, we use git commit to save our changes. Here’s how to do it:

git commit -m "Describe your changes here"

Replace "Describe your changes here" with a brief description of what you’ve changed. For example:

git commit -m "Update index.html with new content"

Output:

[master (root-commit) be9b1cd] Update index.html with new content
3 files changed, 386 insertions(+)
create mode 100644 index.html
create mode 100644 script.js
create mode 100644 styles.css

By using git add and git commit, you’re instructing Git to track and save specific versions of your project. This helps you manage changes, collaborate with others, and maintain a record of your progress.

How to Push Your Project to GitHub

Now that we have our changes tracked and committed locally, it’s time to upload our project to GitHub so we can share it with the world.

Step 1: Create a New Repository on GitHub

• Go to GitHub and log in to your account.

• Click the "+" icon in the upper-right corner and select "New repository."

• Fill out the repository name (for example: "ip-address-tracker"), and add a description if you like.

• Choose whether you want the repository to be public or private.

• Do not initialize the repository with a README, gitignore, or license (since we already have a local repository set up).

• Click "Create repository."

Step 2: Link Your Local Repository to GitHub

To connect your local repository with the new GitHub repository, you need to add a remote origin. Follow these steps:

• Copy the URL of your new GitHub repository. It should look something like this: https://github.com/yourusername/ip-address-tracker.git

• Open Terminal in Visual Studio Code and run the following command:

git branch -M main
git remote add origin https://github.com/yourusername/ip-address-tracker.git

Step 3: Push Your Local Changes to GitHub

Now, push your local commits to the GitHub repository with:

git push -u origin main

Output:

Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 645 bytes | 645.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
To https://github.com/yourusername/ip-address-tracker.git
* [new branch]      main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.

Step 4: Verify Your Repository on GitHub

Go back to your GitHub repository page. You should see all your files and commit history available online.

A Hosted Repository on GitHub

How to Host Your Project on GitHub Pages

Now that your project has been initialized with Git and pushed to GitHub, let’s host it on GitHub Pages. GitHub Pages is a free service that allows you to publish web projects directly from a GitHub repository.

What are GitHub Pages?

GitHub Pages turns your GitHub repository into a website. It's an easy way to showcase your projects without needing a separate hosting service. You can create static websites directly from your repositories.

How to Enable GitHub Pages

• Go to your GitHub repository in a web browser.

• Click on the "Settings" tab.

• Scroll down to the "Pages" section in the left-hand menu.

• Under "Source," select the branch you want to publish from (typically main or master), and choose the root folder.

Selecting the branch and root folder for GitHub Pages.

• Click "Save."

How to Get Your GitHub Pages URL

After enabling GitHub Pages, GitHub will provide you with a URL where your site is published. It usually follows this format:

https://<username>.github.io/<repository-name>

The URL where your GitHub Pages site is published.

Open your browser and paste the URL to see your live website.

Viewing the live website on GitHub Pages.

How to Update Your GitHub Pages Site

Every time you push changes to the selected branch in your repository, GitHub Pages will automatically update your live site. Here’s a quick reminder on how to push changes:

• Make changes to your project files.

• Add and commit your changes:

git add .
git commit -m "Your commit message"

• Push the changes to GitHub:

git push origin main

With these steps, you’ve successfully hosted your project on GitHub Pages. Congratulations! Your project is now live and accessible to the world.

Conclusion

Just a few years ago, I was in your shoes—excited about building my first website but unsure how to share it with the world. Today, you’ve not only learned what Git and GitHub are but also how to use them to host your very own project.

Imagine your excitement when your project goes live, and you can share it with friends, family, and the global community. You've now set up Git, created a GitHub account, initialized a Git repository, and hosted your project on GitHub Pages. Each step has brought you closer to becoming a more confident and capable developer.

This is just the beginning. Git and GitHub have many more features for you to explore. As you continue building and sharing projects, you’ll discover new ways to collaborate and improve your workflow.

Keep experimenting, keep learning, and most importantly, keep coding. The world is waiting to see what you create next!

If you have any questions, feel free to find me on Twitter at @sprucekhalifa, and don’t forget to follow me for more tips and updates. Happy coding!

The version control system used, peer review process, code review process, design review process, how you do CI, automated testing, and manual testing – all vary greatly depending on where you work.

How a company plans, writes, builds, reviews, deploys, and releases software is optimized for their particular use-case, all with their own strengths and drawbacks in mind.

I started reading about how different big tech companies run their Software Development Lifecycles (SDLC) and heard the term Trunk-Based Development a few times. This is a practice Google follows and I was curious about how it's different than the way most other companies develop software.

Two Different Ways to Do Branching

Release Branching

There are two common approaches to enable multiple developers to work on one codebase.

The first we'll refer to as the release branching** method. I've also seen it called feature branching**. But both of these same approaches follow the same general pattern.

Usually via Git, developers all clone the codebase (so they all have identical copies on their machines). Then they make a new feature/release branch based on main, and merge as the work is completed. The emphasis here is that they only merge once, at the end, when all the work is complete – and they merge the whole branch into main.

Here's an overview for how developers use the Release Branch** method:

Release Branching development workflow visualised.

The white dots represent commits, and the bottom solid black line is main. This is a very simple example, as release branches often end up with far more commits than I've shown in the diagram (sometimes hundreds).

Developers branch off main, make their changes, and then when it's complete/has passed code QA, it gets merged back into main. That's release branching.

Trunk Based Development (TBD)

Trunk-Based Development (TBD) is the second approach. Here, each developer splits the work they will do into small batches and merge into main (which is often referred to as the trunk) multiple times.

In small teams, they normally don't create a branch and merge the branch into the trunk. They commit directly into the trunk without branches.

In a larger team (with checks and approvals necessary for MR's), they use short-lived branches. One release branch with 100 commits in TBD would be 10 merge requests with 10 commits each.

In TBD, their code changes generally don't stay around for more than a few hours. They constantly get merged and integrated with the code everyone else is writing.

Jez Humble is a Site Reliability Engineer at Google, and author of Continuous Delivery, who says "branching is not the problem, merging is the problem" – which is exactly what TBD tries to solve.

It aims to avoid painful merges that so often occur when it is time to merge long-lived branches that have diverged histories from the trunk, or even merge multiple branches together into one from different teams/developers before merging with the trunk.

Does TBD Work at Scale?

In a Google talk, Rachel Potvin, who's an Engineering Manager at Google, described one codebase that has (as of Jan 2015):

• 1 billion files
• 2 billion lines of code
• 86 terabytes of content
• 45,000 commits per workday
• 15 million lines changed in 250,000 files per week

They used TBD in this codebase and it served their use cases very well. As Google is made up of many talented (most importantly, experienced) engineers, they rarely break their builds.

Google also has a very thorough, strict code QA process (read about it here) which, when using TBD, allows for fast, efficient software delivery.

TBD also works well for Agile methodologies where you have to ship software frequently to get feedback from your consumers/customers. You can continually integrate and get a good snapshot of your current state.

Let's briefly discuss some TBD strengths.

Strengths of TBD

• Feedback (whether from code QA, or peer review) comes quickly, as you merge daily. This can stop you from doing the wrong thing for 3 weeks, and then getting feedback that your work isn't correct at the very end, causing you to miss deadlines.
• There's a mental benefit to TBD, where developers feel like the trunk is our code, rather than everyone having their own feature branches and thinking this branch is my code. This can foster a more collaborative culture, increasing communication.
• It results in early integration with all the other in-flight projects/tickets and helps you promote code re-use. It's much harder to "use code" that isn't merged into main and you don't know when will be complete. It also stops merge hell when your 9 month old release branch needs to be merged back into the trunk.
• Large projects with lots of work involved are forced to be broken down into smaller deliverables. This is much better for estimating timelines and also for breaking up your code into modular pieces.
• When lots of developers work in isolation on release branches, it can be harder to spot junior developers struggling in their own branch. But if they're expected to be committing their work daily, you can monitor their daily output and assist them when necessary.
• TBD really cleanly ties in with continuous integration. With lots of small, incremental commits to an eventual finished project, you get an always tested, always integrated codebase with (minimal) horrible merges.

Weaknesses of TBD

• One of the challenges of this approach is that you have an increased chance of breaking the trunk, and stopping lots of people from working. You have to make sure your commits run unit tests along with a good code review process so you don't lose time reverting commits all day.
• Your commit history into main will likely be more verbose and it can be harder to see if something is wrong. If you are called at 3 AM and asked to fix a bug on your prod site with some dodgy commits that went on during business hours, would you prefer a day with 1 commit or 200 commits?
• If you don't have a fast build process, you will spend a long time waiting for things to build while your team constantly commits.
• Often times with TBD you are incrementally adding new code to do something new, but you also need the "old" paths you're replacing to still work. Because of this you need to rely on feature toggles (normally from a database) to turn things on and off. This can add an extra level of complexity with debugging.
• A final challenge can be that, when you have constant commits, you are constantly in a state of churn. You need to make sure your team regularly pulls from the trunk and doesn't end up tripping over one another while merging things.

How to Release Software with Trunk-Based Development

Teams using TBD will typically have a different release process than a team using feature branches.

Generally, if you use release branches, you release main whenever you have something that gets merged in (tickets, completed projects, and so on). Or some teams release main on a schedule, like once every week.

Here's an overview of how TBD teams do their releases:

Overview of TBD process

In TBD, branching is used for releases to allow everyone to keep committing into main.

They provide a "snapshot" of your codebase at a stable state, ready for deployment and release.

The only reason the TBD diagram above may need extra details is when something goes wrong with the release of prj-123. Then we commit the result into the trunk and cherry pick the commits into our release branch to get it in a workable state as soon as possible.

Some places, if they are releasing regularly, don't even branch and can just release the trunk whenever it's required. It depends on your company oftentimes.

Conclusion

There is a whole site based on the theory and practice of TBD. Feel free to read more here.

I hope this has explained what Trunk Based Development is and why it's used. It certainly helps alleviate some of the issues around merging long-lived branches containing major rewrites.

I share my writing on Twitter if you enjoyed this article and want to see more.