(…and I’m only 13 years late to the party…)
First of all, I have a confession to make. I’m code shy. At least that’s what I thought I was.
One of the fresh-faced young trainees this year here at NETWAYS, I’m not entirely “new” to the scene. Having gone to university (with varied success) I never was bestowed with the confidence to actually contribute to anything. In terms of feedback, my lecturers and I only looked at what I was doing wrong – yes, admittedly, to get me to stop what I was doing wrong, but approaching code like this made me feel like I was always doing something wrong.
Again, admittedly, I probably was always doing something wrong, but I felt like I shouldn’t contribute, I mustn’t contribute, the only thing I would add to an open source project would be bugs, I would mess things up more than I would be helpful to anybody. I’ve written some small stuff for myself at home, but.. why would anybody rely on my code?
It was an awful feeling. So I never did contribute. And that’s how I became code shy.
Three months into my stint at NETWAYS, and it all changed massively. Apart from my wonderful colleagues, git helped in a big way to give me more confidence, to be more active in my participation, to instill a kind of pride in my work I haven’t felt before – to stop worrying and love my code.
So – why write the millionth paragraph about git?
This won’t be a technical introduction, but rather a little recollection of my thoughts and emotions while getting introduced to git and using it at work – because my mind has been thoroughly blown.
What’s git?
Well, let’s take a look at good ol’ Wikipedia:
Git (/ɡɪt/) is a version-control system for tracking changes in computer files and coordinating work on those files among multiple people.
Version-control? Now, what’s that supposed to mean? Is that like back in the days when I sent my source code files to my professor via mail, so he could check over them and see if I did my stuff?
Well, in a way, that could be some sort of version control system as well – just not a very automated and effective one. Version control is about the general management of files, code, data – it keeps track of changes, who did what, when (and if you’re lucky, you’ll even find a hint or two explaining why), and it allows for reversion of changes and modifications people have made.
My ears perked up when I heard this.
I can go around and mess things up and nobody would get mad at me? I won’t break stuff from the get go? I was amazed.
But how does git do it?
At work we have remote repositories hosted on GitLab, from which I could pull all of the files of the project onto my local machine. So now I have my own copy of the project, in which I could move, delete, add or modify files to my liking – and I wouldn’t break anything doing so, because the remote repository on GitLab would be completely unchanged.
In a way, it’s a sandbox for me, where I can go ahead and code, take care of issues, fix bugs, or add features, test them – until I feel safe to share the work I’ve done with other people. You can see how that is a comforting feeling to have – you can code without worries.
So – what happens behind the scenes?
Git takes snapshots of my work. A snapshot is the way git keeps track of all of the files belonging to a project. Git will checksum them, generate a SHA-1 hash. These hashes are the way git knows about the changes to the code inside the files. After I’ve staged my modified files, I can commit the changes I’ve made. Committing will checksum all of the project directories and store them in the repository – and it will store a pointer to the commit that came before it. This is awesome! So now I can have multiple points to revert the project back to, just in case. But… how would I go about doing that?
Well, let’s talk about branches. Branches are pointers to these commits, the default one being the master branch. There is a master branch on my local machine as well as on GitLab – which made me immediately nervous again. But luckily, I can just branch off of my local master, give it a meaningful name, and even push and store the commits belonging to that branch to GitLab, with the master being untouched. Again, another safe environment for me to go about my work, be more assertive in sharing it, all in a peaceful state of mind.
So – thanks to git, I feel safe in being much more creative and independent when going about contributing to our projects here at NETWAYS – and thanks to the awesome work environment here, I do have space and time to try to add to these projects in a constructive way. My colleagues can look at my code, give me tips and hints, and neither them nor me have to worry about me being a nuisance messing things up.
But what if I’ve finally fixed a bug, or added an awesome feature to one of our projects? Then it’s time to make a merge request. On GitLab, I pick a branch of mine, write a little bit about the new functions or which bugs I (hopefully) fixed, and request for these changes to be added into the master. From there, my fate lies in the hands of the project maintainers…
A successful merge request might just be the greatest feeling of all.
I know that there are a million new ways I could break things if I use git wrongly. So, getting good at git is something I must and will learn at NETWAYS. And – bursting with pride and with a newfound confidence – I look forward to learning more every day.
