When it comes to source code management (SCM), Git is now the de facto standard and a major component in agile development workflows. One of the key features of Git, is that it is by nature distributed rather than centralized. However, when collaborating with others a central shared remote repository such as Github and Gitlab can be used, making it very fast and very scalable. When using Git each developer has a local copy of the full change history of a project. Working locally increases speed and efficiency with the ability to work offline.
Git is a version control system for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source code management in software development, but it can be used to keep track of changes in any set of files. As a distributed revision control system it is aimed at speed, data integrity, and support for distributed, non-linear workflows.
Git was created by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development. Its current maintainer since 2005 is Junio Hamano.
I work in operations and end up writing a lot of scripts and small applications that our team use. After a while keeping on top of them as they change started to get out of hand.
Last year I made the jump from having multiple copies of the same application code, scripts and configuration files, which were scattered all over the place and with slight naming modifications, to managing them with the source code management system “Git”.
As soon as you start using a SCM, such as Git, you straight away you gain the benefits of better code collaboration with your peers, better file organisation and with branching you can “sandbox” ideas and features till they are ready to be merged back in to the production release.
Before using an SCM system it was often very time consuming and confusing trying to figure what changes I’d made to an application or script and for what reason I done it. Especially when I’d written it about a year before.
Also, it’s not very cool or collaboration friendly to hoard a bunch of scripts that you’ve written, especially when a colleague could be caught up reinventing the wheel to solve an issue because they didn’t know a script was already written.
This week after speaking with the developers at my place of work about source code management I discovered that they were still working as I had before. Using shared drives with multiple copies of code with a bunch of comments to keep track of what had been changed. After explaining how I use Git and the benefits I’ve gained they were straight away interested so I demonstrated a basic workflow of a small project.
- Installing git
- Configuring user settings.
- Initializing a local repository for a project
- Staging and committing changes to project files
- Checking the status of a repository
- Checking the commit log
- Setting up a remote repository
- pushing files to central remote repository
- Creating a “feature” Branch from the master
- Merging the “feature” back into the master