Yet another blog post on the top 5 Git commands

Welcome

Hellew hellew everyone! Welcome to yet another blog post on "The top 5 Git commands"! You probably must be wondering how this one would be any different. It won't be. Well, a little bit I guess. I'll be telling you the best resource to learn git at the end, so feel free to skip to the section if you want to ignore all the BS :)

Let's begin then. Starting with the first one:

It's better to light a candle, than to curse the darkness

Here's a random quote because I like it :)

1. git add

   Alright, first up—and one of the most essential—git add. This little command lets you add files to Git's version control, which means Git can start tracking them.

   Here’s how it works:

    git add <file-name> <file-name>
    #or
    git add .
   

   You’ve got two options here:

   • You can be specific and add certain files one by one, or

   • You can take the lazy route and use git add . to add all the untracked files at once.

     BUT! (Big but alert 🚨) – It’s not always considered best practice to go wild with git add .. Picking and choosing files individually can save you from some headaches down the line. That said, I personally think it’s fine to use git add . if you’re working on a single feature and all your changes are related to that feature. No harm done.

2. git commit

   Now onto the second most important command: git commit. This is the part where you save the changes to your local repo. Think of it like a journal entry—Git will remember this moment forever, and you can look back on it later using git log.

   The basic command looks like this:

    git commit -m "The commit messages goes here." -m "A detailed description about the commit goes here (and is optional)."
   

   Now, this command has certain flags that we should discuss.

   The -m flag is the message flag and is used to add a mandatory commit message associated with the commit. You can use the -m flag in continuation to also provide an optional commit description or extra information if you're feeling fancy.

    git commit -s
   

   The -s flag is used to sign-off the commit, using your git username and id. It is particularly helpful to trace back the commit to a person, when co-authoring multiple commits.

   💡

   Tip: Open-source prefers readable and meaningful commit messages, so make it a practice to write meaningful commit messages.

   If you don't know how, here are two resources that will be particularly helpful for writing good commit messages: Conventional Commits and A FreeCodeCamp article.

3. git remote

   Alright, moving on to the git remote commands. Now, git remote isn’t a single command per se, but a category of commands that deal with your remote repositories. So I’m lumping them all together.

    git remote -v
   

   Now this little dude is going to help you check which remote repositories you've got connected. Use this command when you need to verify whether your local repository is linked to GitHub (or any other remote repo), and if it is, you’ll see the URLs listed. It’ll also show you if you’ve got both fetch and push permissions to that remote.

   You should see something like:

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

   But wait, there’s more! Git remote commands don’t stop here. Let’s talk about adding a new remote, because who doesn’t love adding more remotes to their life?

   git remote add origin

   Okay, this is a classic, and if you’ve ever pushed anything to GitHub, you’ve probably run this before. git remote add origin is how you tell Git, “Hey buddy, I’d like to push my local changes to this lovely URL.” That URL is your GitHub repo (or any other remote repo). So, when you clone a repo, this “origin” is usually set automatically, but if you're creating a fresh repository on your local machine, you need to manually add it.

   Here’s how to add it:

    git remote add origin <remote-url>
   

   For example:

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

   Now your local repository is linked to the remote. When you push your code (which we’ll talk about soon), it’ll know where to go. Straight to GitHub. 🚀

4. git push

   Now comes the magic! All that work you did? The code? The commits? It’s time to push them to the remote repository. This is where git push comes in. It’s like sending your files into the cloud to be admired by everyone (or just yourself, no judgment).

    git push origin main
   

   Wait, but what’s "origin" and what’s "main"? Here’s the breakdown:

   • origin: The name of your remote repo. In most cases, it’s the default name, but you can have multiple remotes with different names.

   • main: The branch you’re pushing to. It used to be called "master," but we’re cool now, and "main" is the way.

     You could push to any branch, really. Just swap out "main" for whichever branch you want to push.

     💡 Beware of force-pushing (git push -f). It’s like throwing your code at the remote repo and saying, “I don’t care what you have, this is better.” Use it wisely, my friend.

5. git submodule add

   Let’s dive into the world of submodules. So, a submodule is basically another Git repository inside your current repository. Why would you need this? Well, imagine you’ve got a massive project, and you need to include some other project or library as a part of it, but you want to keep it as a separate entity. This is where submodules shine.

    git submodule add <repo-url>
   

   This adds a repo as a submodule in your project, allowing you to keep it updated separately from your main project.

   Example:

    git submodule add https://github.com/other-project/awesome-lib.git
   

   Now, when you clone your project, Git will also keep track of the submodule’s repo. Don’t forget to run:

    git submodule init
    git submodule update
   

   to get everything in sync.

   Submodules can be a little tricky, so be careful. They’re like having a toddler in your repo—if you don’t keep an eye on them, they can cause chaos. 👶

Extra Tip: How to Learn Git Best

Okay, if you’ve stuck around this far, congrats! 🎉 You’re now equipped with some essential Git knowledge. But how can you become the true Git master you were destined to be?

Here’s the real talk: Git can feel like trying to understand hieroglyphics when you start out. My advice? Don’t just read about it—do it. Get your hands dirty. Make a mess. Break stuff. That’s how you’ll learn.

And if you’re looking for resources (you’re still here, so you must be), I highly recommend checking out Git Immersion. It’s an interactive tutorial that walks you through the commands step by step. Also, Pro Git by Scott Chacon and Ben Straub is a fantastic book, and it’s available for free online.

One more thing: If you’re ever stuck, just run this:

git --help

It’ll tell you what to do with that confusing command you’ve been googling for the last 30 minutes.

Conclusion

And there you have it, folks! Yet another blog post on the top 5 Git commands. Hopefully, you’ve learned something new, or at least gotten a laugh or two. Git may seem daunting at first, but trust me, once you get the hang of it, you’ll wonder how you ever managed your projects without it.

Now go forth, clone, commit, and push like a Git wizard! 🧙‍♂️

If you have any questions or want more Git tips, feel free to drop a comment below. Or don't. I won’t take it personally.