I am constantly on the lookout for ways to better myself as a developer. This includes not only getting better at the actual art of coding but also improving the processes of coding and finding ways to streamline and/or automate these processes. One of the areas that I had already (mostly) improved on is writing useful commit messages, so my git log
doesn't end up looking like this XKCD comic:
One bad habit that is easy to fall into as a solo developer (especially under a time constraint) is to rationalize ignoring or delaying proper documentation since you're the only one working in the codebase it is easy to think that documentation is unimportant. And it is. Until it isn't - and then it is really important.
So that is one area that I am constantly trying to improve in. A git commit message is an oft-overlooked and undervalued form of documentation, so how can we improve here? I had already been, for the most part, following [The seven rules of a great Git commit message]. They made sense and were easy enough to implement, and almost got me to where I wanted to be as far as git commit messages were concerned.
Read MoreRecently I began to wonder if there was a way to have a collection of [git hooks] that could run on all of my git projects to save me the trouble of creating/editing hooks in each of my projects. Yes, it is possible to do this for new projects, via the git config --global init.templatedir
command, but I have a lot of pre-existing git projects that I wanted to add a pre-push hook to, and I wanted to be able to make alterations to this hook after the fact that would affect all my projects. Apparently, I'm not the only person who needed this feature, because it was added in git release 2.9.
Adding the global hooks was easy enough, thanks to this [stackoverflow] answer, but I did run into a couple of caveats after I had the global hooks path set.
Read MoreOne feature that I really like from npm is the version
command which handles bumping either patch, minor, or major version number following the [Semantic Versioning] standards. This sets the version attribute in your package.json
file and creates a [git tag] using the new version number.
For example you can run the npm version minor
command from the root of an npm project and it will change the version from 1.2.12
to 1.3.0
write this out to your package.json
file and create a git tag for the new version.
Since the vast majority of my projects are php projects and not npm, I don't get a chance to use this feature nearly as much as I would like, so I found myself wishing there was a way to do this directly from git.
Read MoreWhen I started my current position way back in the winter of 2013 as the sole Application Developer in a corporate/enterprise environment, I was tasked with maintaining existing web applications, porting Visual Basic apps into a web environment, as well as creating new applications. Each of the php applications that I had inherited had several shared dependencies that were maintained independently in their separate project directories. Any bug that was found and fixed in one of these 'libraries' had to be copied manually to the other projects
Read MoreFull stack application developer. Life-long learner. Pragmatic programmer. Believer in clean coding. Proponent for extensible and reusable code. Hobbies include (very) amateur photography, collecting old jazz records and going to live music performances.
North Central Ohio, US
toddeidson[dot]info
All opinions are my own, probably wrong, and subject to change without notice.
© 2017-2019 Todd Eidson. All content is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.
Hosted on linode