Cover Image Credit: https://github.com/GIT
Intro to Git:
For me, Git was always one of those things I heard talked about, but never really had to deal with until I started my journey to become a programmer. Once I was introduced to it, it felt like having to learn a new language and most of the tutorials I found seemed geared towards more experienced users. So today, I’m going to try and break down the basics of Git and introduce you to the concept of collaborative coding. It’s a powerful tool, and learning Git will be incredibly useful for any developer, no matter what you’re building. I won't be going over very many command examples in this post, but will instead try to break down the concepts in a way that will make more advanced guides easier to understand.
Part 1: Git fundamentals
The way I like to think about Git is that it’s like a save point for your code, just like in a video game. If you make a mistake in a game, but you have a save point before it happened, you can reload and go back to that exact moment. Git works on a similar concept, but instead of save points, it uses things called commits.
Part 1.1: Repositories and Saving code
You’ve probably heard the word “repository” mentioned in relation to code, but it might not be immediately clear what it is. Simply put, a repository is a container that tracks every change made to your code over time. Those changes can be made by you, or by anyone you invite to collaborate on the project. Repositories are the foundation of Git’s commit system as it allows you to see exactly what your code looked like at any point in its history. If you’re just starting out, the benefit of this might not be obvious, but as you collaborate more, you’ll quickly realize how invaluable it is to be able to look back at clean examples of previous code states. It’s not just about fixing mistakes though, it’s also helpful for understanding why certain decisions were made and tracking the evolution of your project.
Part 1.2: Pushing and Pulling
Another fundamental part of the Git workflow is the idea of "pushing" and "pulling" code. This is how we keep our repositories synchronized. Whether it’s updating the central repository with new code we’ve written locally, or updating our local code with changes made by collaborators. When someone says they "pushed" their code, it means they’ve uploaded their latest changes to the repository. Conversely, "pulling" code is the act of downloading those changes and integrating them into your local codebase. Going back to our save point analogy, pushing is like "saving" your game progress, and pulling is like "loading" a saved game.
Part 2: Collaborative Coding
Now that we have a general idea of repositories and how to update code, both pushing changes and pulling from others; it’s time to look at remotes in Git. Remotes can be a little tricky when you’re first starting out, as Git has powerful merging functions that might not make a lot of sense right away, and that’s perfectly okay! Don’t worry about mastering those advanced features just yet. For now, it’s enough to understand that a remote is simply a version of your repository that lives somewhere else, usually on a platform like GitHub, GitLab, or Bitbucket. This allows you to collaborate with others, back up your code, and access it from different computers.
Part 2.1: Git Remotes
The key thing to understand about remote repositories in Git is that Git considers any repository not on your local machine to be a remote. This means it doesn’t matter if you’re pulling from a website like GitHub or from another computer on your local network, Git needs to know where to find it. Thankfully, Git makes it very easy to add and update these remote locations. You essentially tell Git the address of the remote repository, and it handles the connection for you. This allows you to seamlessly push and pull changes, regardless of where the remote repository is hosted.
Part 2.2: Remote Naming Conventions
When you’re starting out as a developer, you’ll often be copying projects from other people (a process called cloning) to your local machine. If you use Git for this, it automatically sets up your first remote, usually named “origin”. You can see a list of any remotes associated with your project by navigating to it in your terminal and running the command `git remote -v`. Here, `git remote` tells Git to list the remotes, and the "-v" flag provides more detailed output, showing the remote’s location (usually a URL). While “origin” typically points to the original repository you cloned from, you can rename it if you wish. However, it’s generally best to stick with the default name, as most guides and tutorials will assume your remote is called “origin”. Knowing this default will save you confusion down the line, and it’s worth noting you can have multiple remotes associated with a single project if needed.
Conclusion:
We’ve now covered the basics of Git and broken down the core concepts to hopefully give you a better understanding of how the process works. The best way to truly learn Git is to use it. Find a project online, fork it, and clone it locally. Then, make changes to the code and try pushing them. Even better, have a friend fork and clone the same repository and make different changes. Experiment with adding their repository as a remote and pulling their changes into your code. This is a great way to see Git’s merging capabilities in action! Git gives you incredibly precise control over your code, and it can seem daunting at first. But mastering these basic concepts will make learning the more advanced features much easier down the road. Good luck on your journey and remember to aim to be at least 1% better today than you were yesterday. Every step forward counts on the path to becoming a more competent developer.
Top comments (0)