I think we should rename the periods in BG and AG. Before Git and After Git. I haven't lived the BG period, as I was not working in web development, but I can only imagine how complicated that must have been. It's like when I think about the good old days when the web wasn't everywhere (yes, there was a time...) and we had to go check a book (like, a real one, in paper and stuff, and usually very big) to solve our programming questions. ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/qihmnfioe9sbv6ec9gph.jpg) Ah those times... there was something about it... But let's focus on what brings us to this post today. Git. **Starting from the bottom. What is Git?** Git is one of many VCMs (Version Control Managers). And why do you need one of those, you say? Glad you asked. 🤓 Imagine this situation: - Jenny and Meryl are working on the same project. They are working on different features. Both features use the same table and so the same DB methods. Then Jenny needs to make a change to, lets say, the update method. At the same time Meryl needs to do a different change to the very same method. Both need to happen at the same time, and both are working on the same code, each on their own. So, how do you handle it? How do you ensure none of the changes get lost on deployment? Well, my dear developer, the answer is... 🥁 you've guessed it... by using a Version Control Manager! 🤯 Situations can get waaaay more complicated than this (imagine several people working on several features at the same time), but for the sake of simplicity, we'll leave it here and move forward. Let me introduce you now to your newest friend: Git. 🎉 **Do you know what Git means?** Well, I started looking online hoping for some kind of acronym, you know, like FTP, HTTP, etc. which actually mean something... and well, nope! As it turns out, Git was named like that by Linus Torvalds, who, you've guessed it, is the creator of Linux. Git is actually slang for *"unpleasant person"* (go figure 🤷🏻‍♀️) and Torvalds would joke about this saying: *"I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'."*

The name "Git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your way):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
- "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks

Extract from [Wikipedia's Git page](https://en.wikipedia.org/wiki/Git) **What's all the fuss about?** Well, if you are a web developer you are most likely using Git... but maybe you don't really know what its benefits are. Sure, there are other version control managers, but Git has become the leader in the last few years, overrunning market leaders like Subversion. ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6ae7qo89kybuj56zg9p5.png) How did this happen? Well, there are a few main differences between Git and other VCMs out there that account for its success: - **Git is a distributed system.** The main benefit being that you can work locally. Other VCMs require for you to be connected to the central repository while working. Git, on the other hand, allows each contributor to make a copy of the project and work on it on their own machine. They'll only commit changes to the remote repository every once in a while. Which brings us to the second benefit. - **It's faster to commit.** For obvious reasons. Since you are committing locally most of the times, commits are faster, no network traffic issues. - **It's available offline.** Which means you can work on your code anytime, anywhere. Connection or not. You can even code while on a plane and use those long flight hours to your code's advantage. - **There's no single point of failure.** Meaning, if the remote repository breaks, you can still work on your own until it gets fixed... and then commit your changes to it. **Isn't Git too complicated?** Well, it can feel a bit like a black box at times. The reality is though, that Git is just an addressable file system. Everything we do can be broken down to simple operations, even done by hand (that would be more complicated, but it's still possible). Let's now dig just a little deeper, shall we? ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/2lllx41ghq9nikyy2uy3.jpg) **The basics of the basics** When working with Git repositories your data goes through 3 different stages: - **Working directory** - The root directory of your project. Any additions, changes and deletions of files and directories done here that aren’t tracked, won’t make it into the repository. - **Index** - Also known as “stage”, is where you decide what changes should go into the next commit. This is what you actually update with the Git add command. Sounds familiar? - **Repository** - This is where the actual data goes and all commits, branches, tags and other things are stored. **And more...** - All of our data, changes and commits are stored as hashes on the file system. - It is rather hard to lose work with Git. Even if we don't create commits but simply add our changes to the index, Git will already store those changes, making it complicated to lose them. - With Git, every single change and commit can be addressed separately thanks to the hashes. - An entire commit history can be restored with a single commit as long as all references are in place. - Git comes with a built-in garbage collector that will remove any Git object that isn’t reachable by any branch or tag. - Git offers different merge strategies for different scenarios (e.g. three-way and fast-forward). - Merges can be undone and cancelled. - With interactive rebase, Git offers the possibility to reorder, split, squash, delete and choose the commits you want to merge to your main repository. - Git allows to run a program after a commit has been replayed during a rebase. - Cherry-picking allows to pick any commit or range of commits in our repository and apply it on top of other commits. **My personal experience with Git** I had been using Git in my personal projects and while this is good and useful, it is by joining Codegram, a web development company where Git is widely used, that I really could appreciate its benefits. All of a sudden things like rebase make way more sense, and working in a team make you realize how complicated our lives could be without Git. Still hungry for knowledge? You want details? You want commands? You want to play with it? 🤙 I feel you. 👉 Then by all means go get hands on with the book that inspired this post: "[Rebase](https://rebase-book.com/)" by Pascal Precht. Photo by [Krista Mangulsone] (https://unsplash.com/@krista?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash] (https://unsplash.com/)

versionconrol

Git is your friend

Join Our Newsletter. No Spam, Only the good stuff.