Git in control of your code — Part 1
So, you have started to work on some software projects after a Bootcamp, maybe with some other people. But after a few weeks, you notice that someone changed the fancy button you have been working on for days!
What an offense!
And it also introduced a bug, straight onto your beautiful webpage.
Whoever did this, needs to pay!
Maybe not.
What if you have some sort of Wayback machine that could help you get back that extra-customizable button? Yeah, that would be awesome right?
Well, my fellow dev, It exists and its name is Git.
In this short series of posts I want to explain with simple terms what is and how git works, so bear with me that I got reserved some nice analogies for you. Let’s get started!
What is Git?
Git is a free and open-source distributed version control system
Simple enough, but what does it actually mean?
Git is free: Yeah pretty straight-forward
Git is open source: You can contribute to this massive project (how? you will learn it in these posts)
Git is distributed: (Things start to get hard) That means that once you want to work on a codebase you clone (those bold terms will be useful later) the entire repository, so all the changes that this codebase has gone through, on your machine, when you finish to change you could push those changes to its origin.
Git is a version control system: Basically, it is a piece of software that manages changes and versioning of your codebase. If you need to collaborate with someone without messing with shared folders and merging code lines, then this is probably what you need.
Git is a software development time machine
Imagine you have a time travel machine that only works with the past, so you could jump to a specific point in time and do whatever you want.
Maybe you want to undo the really embarrassing moment when you got hit in the face by a ball, or you want to get a better score with your final test or even get another chance with your high school crush. All those changes could lead to an infinite amount of parallel universes.
A machine like that could be useful for sure, and git is just that (for your code)
What does Git?
Git helps you go back to all the changes that you have made in your code and revert the current state to a specific point.
Imagine you have your timeline of code, you start writing stuff, change lots of things, maybe introduce a new library for JSON parsing.
Then you find out that this new JSON parsing library is not what it suits you, so you want to go back to when it all started; Yeah CTRL+Z may be a good solution, but what if days passed? what if the “undo-memory” is not covering all those changes? then you have a problem.
Git helps you get back to that moment and rollback all the changes you have made.
So that you could have a better implementation for JSON parsing, or even undo some changes that injected a bug into your software.
That’s the basic use case of Git, but as I said before, it is not the only one. We could also explore different universes.
What if instead of adding that JSON parsing library, I made it myself?
Not a wise decision for sure but bear with me.
With Git I could create a new branch of my codebase from a point in time and have like 2 versions of the same reality.
Then I could add some changes to that new reality, like the JSON parsing code or some bigger feature to the software.
Ok, fun trip, but how could I go back to the original reality? Simply enough Git helps you merge those changes into the master reality, and it will apply all the changes you have done in that parallel universe to the master one.
Cool, how do we do all this cool stuff?
Some Git useful concepts
Unfortunate for you, this won’t be the only chapter for Git so let’s start with the basics concepts (some earlier words will be more clear to you).
branch: A timeline on which you could apply changes to your code, it consists of a set of changes called commits.
master: The branch on which you start your repository, should be like your reference for all the changes in your code.
merge: The action to join two different branches will apply all the changes from one branch to another.
commit: The action to set a point in time on which you could return, is fundamental because those (commits) are the points to which you could revert your code.
repository: It is the place where all the changes are stored. (to git is the .git folder)
clone: The action to copy the entire repository onto a target machine (e.g. yours) to apply changes etc.
pull: The action to get some commits from the origin to your local repository.
push: The action to send some commits to the origin from your local repository.
origin: The repository from which you cloned your local one, usually is stored on a VCS service/server (like GitHub, GitLab, bitbucket), and it is the reference for all the devs that want to get/add changes to the codebase.
staging: The action to prepare a file for the commit, basically to tell git to add that file to the next commit. (sort of preparation state for the commit)
As I said, this won’t be the only post on Git from me. The next step will be a practical article on how it works and some commands to create and act on a repository. (With some GitHub involved)
I hope this introductory article helped someone understand some basic concepts around it
Let's git down to business
