I use git every day at work, for managing changes to codebases that I contribute to.
You can extend git using aliases, which a lot of people use to create shortened forms of git commands. Why type
git pull --rebase when you can alias it to
git pr and save yourself a bit of effort?
For more complex tasks, you can create custom git commands using your own scripts.
Creating a command
git <SOMETHING> requires you to put an executable script called
git-<SOMETHING> on your path. That’s it.
Git itself will then call your script when you use your custom command.
I try to write my commit messages according to the conventional commit specification. It lets me tag each commit with the type, and scope, of the change so I can more easily introspect about the types of work I’m doing.
I’ve written a custom git command,
git conventional-commits, that lets me filter my git history based on which type (or scope) the commit has. I also added a
--json flag so I can pipe the output into something like
jq for post-processing.
$ git conventional-commits -h usage: git-conventional-commits [-h] [--type TYPE] [--scope SCOPE] [--json] Log and filter conventional commit messages optional arguments: -h, --help show this help message and exit --type TYPE Type of commit --scope SCOPE Scope of commit --json Format output as JSON
git-conventional-commits in plain python3, made it executable, and copied it into my
/usr/local/bin, which “Just Works”.
Git commands are a great way to perform more complex operations than you could only using git aliases and since they’re separate scripts you could version control, test-drive, and publish them as you would any small software library.
November is National Blog Posting Month, or NaBloPoMo. I’ll be endeavouring to write one blog post per day in the month of November 2020 - some short and sweet, others long and boring.