Table of contents
A friendly introduction to Git
The content here is under the Attribution 4.0 International (CC BY 4.0) license
Git has stabilized itself as the de-facto standard versioning control system, developers got used to it (despite it being a not-so-newbies welcome tool) and Git has an ecosystem that helps to ease the learning curve. GitHub has emerged as an open-source platform, and GitLab is an integrated DevOps platform that runs based on Git.
Git is used for code analysis to provide insights for decision-makers. Tornhill used git to construct code analysis that reveals hot spots in the code based on criteria such as design issues and knowledge silos [1]. Through git, those become data-driven and visually accessible.
In the next section, we will dive into the history of git how it intersects with SVN and the differences between both Version System Control.
What is Git, and why should I use it?
In the early days of software development, programmers used to write code and push it to a main server. This worked great in the ’90s and, believe it or not, it still does nowadays, but of course, there are more elegant solutions to today’s software development.
Linus Torvalds, the Linux creator, had a big issue when he was trying to develop other systems and keep them versioned, from this point on he decided that he would just end the software when he had a good versioning system, and then Git was born.
Back in the day, SVN was the main version system used by programmers and it was like a main server where you could push all your code to it.
https://bhrugeshblog.wordpress.com/tag/subversion/
The image above shows it very clearly to us: it is a main server where every client has the entire code. It is a copy and paste in each client machine. The arrows on the right side are the operations that developers do in a common repository. Updates mean that each client machine will get only the fresh new version from the main server, and the commits are what each client does before pushing code to the server.
The big problem with SVN(Subversion) is that it doesn’t work in a distributed way, you can only have a main repository where it needs to be online, SVN is even more complex because each commit is an entire “photograph” of the entire repository. This means that even if you change one single line in your code base, SVN will “take a photograph” of your entire repository and it makes it hard to sync.
Git is a distributed system to contribute among programmers. It makes versioning easy and the collaboration works better. Git works oppositely compared with SVN, it is distributed instead of one single point. Which means that every client can be a main server.
Git also takes care to not create a new copy of all files when a change occurs to a single file, it’s smart enough to send to the server only what has been changed instead.
Git features
In this section, we are going to examine essential git features and how to properly use them. If you are new to git you must read this section, if you are not I´d recommend reading it just to review the content. Git has different features ranging from the most basic ones such as commit, clone, push, and pull to the more advanced ones, cherry-pick, rebase and bisect. You don’t need to memorize each of those commands but rather understand what is the purpose of each one and what problem it tries to solve.
First, Understanding the repository is the key to proceed “Repository : a place, building, or receptacle where things are or may be stored.”
refs http://www.merriam-webster.com/dictionary/repository
On the one hand, the dictionary says that a repository is a place where we can store something, on the other hand, to us in the computer scope it is an abstraction. Indeed, a repository is where we store things but in git, it means the source code (you can store any kind of data with git, but for simplicity let’s assume only source code), the repository is where the source code stays and is pushed to.
One of the chapters of Peter Goodliffe’s book is dedicated to Version Control Systems, and he uses git as an example - but it could be any other, i.e. Mercurial or SVN. He says that every programmer should master their skills with version control and also tells us a little story about what he had been through with a team that didn’t use a version control system.
The team usually sends the code to an email at the end of the week after a long week of coding, he calls it “Distributed Data Loss”.
If you think it is something absurd to send source code through an email, what advantages do we get using a Version Control System? Peter has answered it in the following items from his book (page 171) [2]:
- It provides a central backup of your work.
- It provides the developer with a safety net. It leaves room to experiment, try changes, and roll them back if they do not work.
- It fosters a rhythm and cadence of work: you do a chunk of work, test it, and then check it in. Then you move on to the next chunk of work. For example, a single git init command in a directory establishes a Git repository in a heartbeat.
- It enables multiple concurrent streams of development to occur on the same codebase without interference.
- It enables reversibility: any change in the history of the project can be identified and reversed if it is found to be wrong.
Before jumping into the next section, give it a try this resource uses gamification to teach the basics of git. It is an alternative for newcomers to git as it uses analogies to make the experience of learning git less frustrating.
Installing Git
From now on you need to have git installed in your operating system. If you do not have it yet, follow this link to install it.
The command line will be your friend as well, all the commands are executed on a terminal. GitHub provides an interface to handle it but for learning purposes, it is recommended to use only the terminal.
Checking installation
In a terminal window, running the command git --version, should give a similar output:
git version 2.45.0
References
- [1]A. Tornhill, “Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis,” Software Design X-Rays, pp. 1–200, 2018.
- [2]P. Goodliffe, Becoming a Better Programmer: A Handbook for People Who Care About Code. " O’Reilly Media, Inc.", 2014.