When we implement a new tool or system, there’s always a process of getting to grips with new vocabulary and pinpointing the steps to make things happen; so we wanted to publish this blog to give you further insight into our attitude towards development, whilst explaining our decision to use GitLab for source control.
Ctrl-alt-del & forget
So, you want to make a change to your WordPress site: you fire up an FTP connection, locate your file, download it, make the necessary changes and upload it back to the server.
If you went back to make another change to the same file a day later could you remember the change you made? What about a week, a month, or worse, a year or more?
Unless you’ve added commentary to your files, or taken numerous backups, this kind of change management quickly becomes cumbersome, not to mention tiresome, stressful and inefficient.
If that’s your current workflow, you’re not alone. Everyone starts out with a process like that, but there’s a much better way of doing things.
Source control is a formidable safety net. It’s a system that tracks changes and stores information on who changed what and when.
We’ve all been faced with a situation where a colleague is absent, and a recently-amended document is locked away on their system. GitLab allows us to store code in one secure place, meaning that you’re never locked out if a change needs to be made. Any of our developers can tweak code that they’ve been given access to.
Whilst we had been using standard Git on some legacy projects, this was not being adhered to across the board. We now use source control via GitLab for all new projects, primarily for the reasons above, but also because of its intuitive UI, two-factor authentication and because it’s self-hosted, which is crucial for our security considerations. Code is still managed using your favourite toolkit; Unix/Linux bods prefer the command line, whilst some Windows developers prefer GUI tools.
If a client isn’t 100% happy with a change we’ve made, we can look back through commits and revert back or apply further fixes easily. Think of it as the ultimate undo button.
Why (and what is) GitLab?
GitLab is a web-based repository that allows us to monitor projects of different sizes with speed and efficiency. It helps us manage code, communicate and collaborate on different tasks. You can think of it as a time machine which allows us to go back to wherever you’d like in the code’s life cycle.
Basic issues can be solved easily, and it also allows us to manage larger projects, pull back overwritten work and lift pesky restrictions – allowing all involved to work with less interference or boundaries. Working with GitLab is so much simpler and much more light-weight.
With so many tools available to developers, GitLab has become the place to be for open source software.
The system provides a staging area to prepare commits, before adding them to the main code base. It makes changes more visible, gives you greater control over how you track the history of your work and improves the quality of the code being committed. If you want to see the changes made, it’s as simple as clicking on the commit and assessing the differential.
GitLab isn’t a mercenary tool – you can use it to track your commits, collaborate with others, pull requests and control project flow. We can even add external users to the system with limited permissions to allow remote users or even stakeholders to have access to the code base or issue tracking.
As a source control system, it does a great job of keeping track of revisions. Its strengths lie in the workflows that can be built right on top of it – making it a lot easier to work independently and merge changes with less difficulty.
GitLab is overflowing with features and options, and our projects are all the better for it. The question is: where will it take you next?
Comments are closed here.