I started hearing about Git about a few years ago (I think I was in the first or second class of my study, am in the fifth now). I understood the concept but found it really hard to work with, as in, so hard that I just didn't use it. It kept coming back again and again and a few months ago I thought: Fuck it.

What is one thing that a lot of devs are good at? Automation, exactly. So, I had a GitLab account (idc about their recent fuckup, will keep using it) and had to keep asking people to set stuff up for me.

I started to do research and stumbled upon the empty repo page from GitLab which provided clear instructions on how to locally do stuff so I could interact with a remote repository. Then I started to bash script.

After one day, I had a fully working bash script which, with just two parameters, initiates a new repo, clones it locally, creates a README.MD and commits + pushes it.
Then I put it as executable in the /usr/bin.

So now, whenever I start a new project, I just have to create a directory, go into that directory and call a command with two parameters and I'm good to go!

Actually pretty proud of that, although it might be the most usual thing for a lot of peoples, I wrote a workaround/automation thingy for the thing I find the hardest in development :).

What the flying git did I just do.

So here I am, finishing my billionth.. ok maybe not that many, feels like it some days.. task so I do the following:

git add /path/to/file.ext
git commit -m "yay done for the day" /path/to/file.ext

- yes I specify the files in a commit, I've had bad days in the past, plus I can work on multiple files at a time -
But anyway...

Then all of a sudden 20 other files are now staged for commit 🧐🤪🤭😱🤯

Wtf!

Guess I'll be sorting this mess out before doing a push tomorrow morning.

So I am finally plunging into continuous integration. If I make one more deploy script mistake, I've lost enough time to merit having learned a better solution than bash scripting calling git and rhc and py files I wrote. I have failing tests that are failing because they weren't updated after the million and a half urgent changes in the past 2 months, so it's time to act like I am a TDD fanatic and write the tests correctly. So much work. All from me listening to the constant req changes, listening to the urgency, letting non-devs get under my skin if you will. I'm optimistic in all the wrong places - I think I can write that by end of day let's try it. I'm lazy in the wrong places - I think that I can write that test later, because all I changed was XYZ (which took all night but I said I'd get it as close as possible didn't I?). And I think these handful of bash scripts are good enough to make sure I run tests? But remember, I didn't write the tests or I didn't go back and update them. Or the tests that fail, I'm too lazy. And so much of the tests, I would need to use, idk selenium for, and damnit if I really don't want to dig for element IDs to wait for every time I need an AJAX call.

Okay wow, I really did rant here. And discredited myself a bit lol I need to ignore the wrong lazy and embrace the right lazy. Protect myself from myself and from contributors. It really is, up to me now, to rescue myself from my bad habits. Bad habits perpetuated by clients urgency every day, to change things, that should have been finalized in November if we wanted a stable flipping system in January. It feels like the blind (client) leading the blind (me, when I do dumb shit like rush features out the door half tested).

Anyway all this came out, because I have been reading about continuous integration and stumbled upon this quote. And thought someone might laugh at the anachronism like I did