Git is great and useful. At Byte Internet our developers use Git and so should you! Not only when you work in a team of developers but also when you work alone. In this article I’ll try to explain why. Git is a free and open source distributed version control system, designed to handle everything from small to very large projects with speed and efficiency. It can be used to create and maintain software as our tech dudes do, but it can also be used to track changes to a website like I do. I’ve used Git for solo projects but also in groups with other developers. I like it. It saves me time, provides me with versioning and a backup of my code.
The most important reason why I love Git is because it saves me a lot of time. With Github I can save versions of the projects I’m working on. Every time I commit a change to the code I also add a note on what I’ve changed and why. I can easily view all commits and browse through my notes for every change I’ve made. I can compare two versions of earlier commits and roll back to one of them if needed.
Using Git is not very useful for tracking non-text files. Files like images, movies, music, fonts, word processing files, spreadsheets and pdf files cán be committed to Git. However the changes cannot be tracked since they are not text-based files. Only the changes of text-based files can be tracked. On Github you can both compare changes as add comments to the changes of others. Not everyone will be working in the same place at the same time. With this option you’ll have the ability to discuss the changed code where it belongs. Next to the code itself.
Git — everything is local
Git is also distributed. Which means that every developer working on the repository has a full copy of the repository on his or her own machine. Changes are committed and pushed to the repository. When a developer’s computer crashes only his locally stored non-committed, non-pushed changes are lost. The repository will remain intact.
The quote mentioned above comes from the website git-scm.com This site learns you how to use Git using commandline and/or a gui. I highly recommend you to bookmark it. Together with github.com and codeschool.com they’ve created a clickthrough tutorial which makes you familiar with Git within 15 minutes.
Learn to work with Git in your browser for free: Try Git.
There are many usable Git workflows. For our Joomla based website @Byte I’m the only developer at this time. In my development environment on my computer I create feature branches for every new feature I want to implement. I commit every change of code for that new feature into a specific feature branch. And when I’m done I merge the feature branch with the master branch. To test the new feature I pull the changes from the master branch into the testenvironment of our website. When everything works as it should I pull the changes to the production website. When the feature is implemented the feature branch can be removed.
When you work on bigger projects or software with more developers, another workflow is more appropriate. Three years ago in January 2010 Vincent Driessen (@nvie) wrote a great blogpost (A successful Git branching model) about a development model he introduced in all of his projects. His workflow consists of more branches. A master and a development branch in the core and a couple of supporting branches like feature branches, release branches and hotfix branches.
The Git branching model by Vincent Driessen is a workflow that can be easily understood. By no means is it a rule that you have to work with. Just like I did, you can work with your own model. It’s totally up to you how and íf you work with branches in Git. I think I might expand my workflow by starting to use hotfix branches for quick fixes to the website.
Git and Github
In this blogpost I use the words Git and Github a lot. Git is the distributed version control system which can be run on your own Git server locally or remote. Github is remote server where you can manage your Git projects. But not only that. Github is also a community of developers working on their own repositories or working in organisations with both private as public repositories. Using public repositories anyone can create a copy of or fork your work. Ideal for working on open source projects. Just fork the project, create a new feature branch and ask the owner of the original repository for a pull request. Your code attribution might be merged with the project and you will have shared your knowledge for the benefit of everyone.
I like to work with Git and so do all my colleagues at Byte. I hope you are convinced and are dying to dig into Git yourself as well. Visit our public repositories on Github. -> https://github.com/ByteInternet