Git pickaxe

You can search through git history not only by the text of a commit message but by the contents of the diff of commits. This is commonly referred to as the git pickaxe and you invoke it with the -S parameter to git log i.e. git log -S 'public void SomeMethod and you’ll get every commit that touched that method signature or even one that deleted it. Some git clients will expose this as an option in a search field but if that fails the git cli lets you include additional filters like author or file path or even use regex with the --pickaxe-regex switch. ...

Git Extensions git client

The Git Extensions git client is actually pretty powerful and has a lot more features than I thought. I’d seen others using it before but never looked into it until I saw a StackOverflow answer suggesting to use Git Extensions to view the git reflog… a feature I’ve only ever seen in Smartgit. Some nice features I noticed while playing with it for a bit: View commits from the reflog in the log view (makes it really easy to recover commits) Option to view First Parent only in the log view Stage individual lines Option to launch external editor for commit message The commit message window can autocomplete file names Show/Filter any number of branches in the log view Windows file explorer integration Completely free and open-source and cross-platform I think I still prefer Smartgit over Git Extensions but it’s tough to recommend Smartgit since it requires a license for Commercial use so I’m always keeping an eye out for good free options to recommend to others and now Git Extensions is my new recommendation (much better than SourceTree).

Use `core.hooksPath` for shared hooks

Sometime around 2019, git added the core.hooksPath config setting to change the directory where git will look for hooks. This is handy for commiting shared hooks into a repo so you no longer need workarounds like a script to copy them into the default $GIT_DIR/hooks folder or creating symlinks or relying on tools like Husky. This post is a good example of how you can use it.

Git Config Settings I Always Recommend

If you’ve ever worked on a project with me then I’ve probably recommended at least one of these config settings in git. git config --global pull.rebase true - tells git to always pull with rebase instead of merge (the equivalent of pull --rebase). This not only saves you having to type the flag every time, but also ensures gui clients will also use rebase when pulling. Note: You should only enable this if you’re comfortable with rebasing. git config --global fetch.prune true - tells git to automatically run git remote prune after a fetch. This will clean up any local objects that no longer exist on the remote like tracking branches that have been deleted from the remote server. git config --global rebase.autoStash true - tells git to automatically stash when you perform a pull and then attempt to unstash them once the rebase is complete. This is almost always my workflow so it’s nice to have git do it for me. git config --global rebase.autosquash true - tells git to automatically include the --autosquash parameter when doing a git rebase --interactive. You should read more about autosquashing commits if you’re unfamiliar with it. I use it all the time for fixing up or rewording previous commits. Newer settings If you haven’t updated git in a couple years then you should as it’s worth it just for these new config options. ...

 ·  · 2 min · 

You Should be Using Git Hooks

In my opinion Git hooks are an incredibly useful yet under-utilized feature of git. There are lots of resources that go into hooks in detail but here I’m just going to list some of the ones I find myself using over and over again. prepare-commit-msg This hooks is great for templating your commit messages. This post does a great job of highlighting some powerful possibilities. I like to use it to automatically insert a ticket number from the current branch name. ...