rake, psake, grunt, gulp, jake, make, cake, brunch, ant, bash, maven, or fabric. as long as you putOnAHelmet
A standard task I began placing in my projects lately is one that easily integrates with my build tool of choice (rake, psake, etc…) and when run, installs a git pre-commit hook into my local copy of the repo that will run tests before code is committ. I’ve fancied calling the task putOnAHelmet.
Come checkout a small little github repo I started to keep track of various versions of this and feel free to open an issue or send a pull request with another one!
I don’t want to get into details about pre-commit hooks and how you should author them in this post (maybe we can expand the language in the repo’s readme…). You can also check out other writings… But one of the biggest problems I have with them is gits in-ability to easily keep track of pre-commit hooks much like it can with the rest of the projects source.
Now it’s true that different people need the ability to customize these, but a general “running of tests” before committing is a great first step and I’ve found these set of tasks the easiest way to carry them from repo to repo.
Hope others find this useful!
Happy committing!Read More
If your not using source control for your coding projects, get off my lawn. (#JustHadToSayIt)
Now that I’m only reaching people who use source control (serious developers), I’d like to ask that you focus hard to only commit changes that belong to a single topic at a time. Think SRP for code commits/check-ins.
What is a topical commit?
That almost looks like ‘tropical’ and wouldn’t it be nice to be in a tropical place doing commits to your code, but I digress…
The topics I’m referring to are specific functional units of change where each tiny commit is related to a single topic or theme.
- adding feature X
- bug fix
- spelling fix
- Updating comments/documentation
- *** code formatting ***
I highlighted that last one for a reason as it’s the impetus for writing this post.
Don’t mix topics/themes within a single commit!
Instead break them into multiple commits. If you’re using git, checkout ‘git add -p‘
If you have a one line bug fix but the file has 20 lines of code formatting changes (you know who you are). It makes determining what the bug fix is nearly impossible from the changes that are code formatting.
Using tools like git bisect to look at history become difficult. Pull Requests in GitHub become difficult to understand. If you’ve left a codebase for a while and come back, try reading changes that have happened over time to get caught up can be extremely difficult to do if your commits are not topically based.
Let’s just NOT mix topics in our commits, ok?
K, THX bye!
Happy Coding!Read More