I’ll be honest … I need some Git training. From time to time I contribute small things to GitHub projects and sometimes get confused with all the commands.
Pull Request … all things that mean something to me, but that I certainly haven’t internalized. And so it happens that I sometimes mess up a pull request or something similar.
Sure, my blog here also lives in GitHub, both in terms of source control and hosting on GitHub Pages, but here I’m the only one committing. No issues, no branches, no pull requests or anything else. I change something, hit commit and I’m done.
Another point I can’t dismiss: I’m a Windows guy who likes to click buttons. The command line is not for me at all.
What was the name of the parameter? Do I have to write
/param:xxx … damn where is the button?
My brain is probably too small for that.
Visual Studio Code is a big help there … it has buttons! But that doesn’t save me when it comes to Git, because you have to know in which order to press which of these buttons!
Yesterday I discovered a small bug in my favorite Mastodon client Elk, which could be solved with one line of CSS. So … cloned the thing, looked for the source file, inserted the line … and googled how to submit the change on my repo clone as a pull request to the Elk project, and found this great tutorial on Medium from someone, with the name Supritha:
Fantastic. The pull request was a breeze. BUT … on the pull request page of Elk on GitHub the first check threw an error regarding Semantic Pull Request, with the message the title was wrong … what the heck?
While I was reading the documentation (after the first attempt to change the title to something reasonable and another failure), one of the Elk developers Joaquín was so nice and corrected the title and pointed me to the very doc I was reading:
Okay … I was already happy that nothing went wrong this time, but that was too early, as so often in IT ;)
Since I am a structured person, I liked the commit message rules used by the Elk team, because they open up a space to make the commits easier to evaluate automatically afterwards. I think a great help for projects of this scale … currently 202 contributors!
Actually I don’t have a Git project where the Convertional Commits would be useful, but for my future Me … READ THIS POST!
(And for my employees, in case they read this: I have an idea that we should definitely establish soon … ;)
You can interact with this article (applause, criticism, whatever) by mention it in one of your posts or by replying to its syndication on Mastodon, which will be shown here as a Webmention ... or you leave a good old comment with your GitHub account.
In case your blog software can't send Webmentions, you can use this form:
No Webmentions yet...