Git is the most widely used version control system in the world at the moment. You can’t however, talk about Git without mentioning GitHub. You may have seen the term GitHub used in different places across the internet, that’s because quite a bit of software that exists in the world at the moment has an instance hosted on GitHub. But this post isn’t about GitHub so we’ll leave it there for now. At its core Git is a software that allows developers to create code versions that enable them to track the progress of a project. This post isn’t a Git tutorial so I won’t go into detail about Git commands. Instead I’ll be looking at some of the benefits of using Git as a developer.
This is the management of changes to documents, in this case files that contain a particular software’s source code. Whenever a developer updates their code stack they can take a snap shot of the whole project and save it as what’s known as a commit. Commits can be saved on a remote repository.
In my opinion, this is the number one reason why as a developer you should be using Git. Before I started using Git there were numerous instances when I lost bits of code because I didn’t have a solid plan for backing up my code base for a project and neither did I have a way of reverting to previous versions of that project.
This is simply working together to achieve a common goal. As a developer, often times you have to work on a single project with other developers and share code samples to build one end product. Git was designed with collaboration in mind. Git gives users the ability to push (upload) as well as merge (download and combine) different sections of projects and settle any conflicts that may arise, definitely easier and more intuitive than sending each other zipped versions of code.
Setting up Git on a remote server allows code files to be easily moved from local environments to remote environments. This comes in handy for deploying your project to a production server. Git can be configured in such a way that when changes are pushed to the remote server they are immediately implemented on the production server as well. This means that with a few commands on your local environment you can; create a snapshot of your code, create a remote backup of the snapshot and publish the changes to a production server. No need for logging into dashboards and consoles to upload and apply changes. More info about this topic can be found here Push-to-Deploy.
One of Git’s main collaboration functions is branches. These allow different features of a project to be developed separately and later merged to make one end product. Approaching a project in this way inherently encourages a certain level of organisation because the team has to plan, divide the project into features and then allocate a resource to develop the feature on a particular branch.
Fair enough a certain level of planning must go into any project, with or without Git. However, using Git ensures that planning is never skipped and that those plans are easily quantified and assimilated into the big picture.
Git has two interfaces for executing its functions, a command line interface (CLI) and a graphical user interface (GUI). I prefer the CLI because I feel it gives me more speed and flexibility whilst also getting me to interface with linux environments, which is a useful skill for any developer. The official Git site will however, tell you that both interfaces can deliver what an average user needs.
Some of the tools that you’ll develop skills on whilst setting up and working with Git include; SSL keys, linux commands, SSH terminals, linux file structures and more.
Those are some of the reasons why I think Git is such an awesome tool for any developer. If you haven’t started using it then I strongly urge you to have a look at it. You won’t regret it.