Git is the ultimate tool that every developer must master. That’s 36 million users and 90% market share. If you’re not perfectly up to speed on this wonder, it’s worth investing seven minutes of your time.
Once upon a time
It is April 2005 and the living legend Linus Torvald is working a lot on his baby: Linux. It has been working on it since 1991 and you can imagine it: the project is huge. There’s a lot of code. There are even more people working on this code. To manage all this mess, Linus went to the BitKeeper version management system.
The problem with BitKeeper is that it is primarily proprietary software. Already, it annoys part of the open-source community around Linux. Also, the free version comes with very difficult constraints. As if that were not enough, overnight, the free version of BitKeeper is removed.
Immediately, Linux Torvalds rages and decides to completely code its versioning system . Git’s ÉCLAIR development was about to begin.
On April 3, 2005, Linus begins to work on Git. On April 6, 2005, he sent an email filled with rage where he announced that he was working on an alternative solution. On April 18, 2005, the first branch merges are working! On April 29, 2005, Git begins to be used in certain parts of Linux. The June 16, 2005, Git fully managed version 2.6.12 of Linux.
Shortly after, Linus decided to hand over the keys to Junio Hamano, who made it a version 1.0 deployed on December 21, 2005. Today, Git is everywhere.
What is Git?
Git is an open-source distributed version control system. Concretely, it is a tool that allows you to track all the files in your project. Each file modification is then detected by Git and versioned in an instant version. A modification history will be available on your project. You will be able to consult it and why not even go back in time!
Git is a tool that will let you know who has touched which file, when, and how. Imagine, you have 2000 files and 5 developers working as a team on it.
- How do you know who did what and when? Git versioning will let you know.
- How can you be sure that developers are not bothered by touching the same files at the same time? Again, Git to the rescue with its branch system.
Each developer will be able to work in parallel with their copy of the project on a personal branch. Once their work is finished, the working copies will be merged!
On top of that, unlike some of these competitors, Git is decentralized. This means that the history of files is present in each of the machines where the project is located. This differs from a centralized architecture where you can not do much without a single server that manages everything.
Well, it may not be entirely clear yet, let’s see how it works!
How does Git work?
The first thing to understand with the operation of Git is that it takes snapshots of your project to version it. Where other versioning systems like Subversion and Perforce will make diffs on each file. This difference is important. It will allow Git to distinguish itself in terms of performance and developer work in parallel via the branches!
Second things to understand with Git: work areas. There are several areas where your project files will live in Git. It is super important to understand this part so as not to be lost.
There are three distinct areas locally on your workstation .
- Working Directory: this is where your git repository is initialized and your files live. This is where you touch all of your files while you work. Once you want to version a version of your project, you will then type the command “git add <file>” to move a file to the next area.
- Staging Area: the staging area is where you designate the files you want to version. You can see the command “git add” as a way of putting things in a box. Once you have designated everything you want to put in this box, it will be ready to be sent to the repository with the command “git commit”.
- Local repository: the deposit area is where the famous snapshots of your project are versioned and stored. The important thing to understand is that a version reference is created for each commit you make. Each commit is therefore a version of your unique project that will live in the repository and that you can consult/compare when you want!
And for the moment we stayed at your workstation. Once you have a version as you want you will be able to share your work by pushing it on the remote repository via a “git push”. Before explaining to you all these tricks of fifou, drawing!
These are the four commands that you will use all the time and this is the flow that you will have permanently. Now you are bound to work with other developers. To manage this well, you will have to use the branches.
Showing the Git order
To install Git, you will find your happiness here. For the little demo, we will imagine a scenario. It’s not going to be hard to imagine: this is what will happen to you all the time.
- 1: Update the main branch
- 2: Make a branch to work in your corner
- 3: Make multiple commits
- 4: Reduce these commits in a single commit
- 5: Push your changes to the remote repository
I assume that you already have a local Git repository that you cloned from a remote repository using the git clone command. Let’s start by updating the main branch. As of this writing, by default, git will name its main branch, master. In the future, it will surely change. So that you don’t get lost the first time, I use the default name.
git pull origin master
The command used git pull to update our local repository with updates from the remote repository. Then we create a branch.
#long version git branch feature / learn-git git checkout feature / learn-git #short version git checkout -b feature / learn-git
With the command git checkout -b we will create a branch (a copy of the main branch) and place it automatically. I’m using the name feature / learn-git here. Putting the suffix “feature /” in the name is a good practice that you should take when you create a branch to make a feature.
When working with Git it is also advisable to commit frequently . This is what we are going to do here.
# you're supposed to be working on files here git add. git commit -m "I'm learning git!" # you're supposed to be working on files here git add. git commit -m "WIP" # you're supposed to be working on files here git add. git commit -m "WIP"
Before pushing on the remote repository, we will clarify our work by reducing everything to a commit with a clear message.
git rebase -i HEAD ~ 3
git rebase will allow you to rewrite the history of commits in your branch. The -i flag allows you to do this interactively. HEAD ~ 3 allows you to do this on the last three commits.
This will open a window in which you will indicate that you want to “squash” the last two commits in the first. Then, a second window where you will redefine the message of the final commit.
Finally, it only remains to push your very own branch on the remote repository!
git push origin feature / learn-git
And There you go ! You have the basics to use Git everywhere!
As usual, five minutes is too short, so we went to seven minutes today. I hope I made you want to learn more about this fabulous tool that you will use every day. An advanced article on Git is coming in the coming months. We are going to talk about git flow and more specific commands like git bisect, reflog and cherry-pick!