Git is actually sooo hard. Not just to learn, but also to use consistently. And I say that as a person who used it for probably over ten years. Here’s my thoughts on the matter.

Daniel Stenberg:

Every now and then I get questions on how to work with git in a smooth way when developing, bug-fixing or extending curl – or how I do it. After all, I work on open source full time which means I have very frequent interactions with git (and GitHub). Simply put, I work with git all day long. Ordinary days, I issue git commands several hundred times.

I have a very simple approach and way of working with git in curl. This is how it works.

A nice, visual way of learning the most common git commands and how they do what they do.

bit is an experimental modernized git CLI built on top of git that provides happy defaults.

This is not a tutorial on using Git! To follow along I advise that you have working knowledge of Git. If you’re a newcomer to Git, this tutorial is probably not the best place to start your Git journey. I suggest coming back here after you’ve used Git a bit and you’re comfortable with making commits, branching, merging, pushing and pulling.

There’s a lot of information that you are ignoring from your VCS. SQL is a great way to access it.

Following Git 2.28’s highly sought after ability to configure init.defaultBranch comes GitHub’s support at the platform level.

You can now set the default branch name for newly-created repositories under your username. This setting does not impact any of your existing repositories. Existing repositories will continue to have the same default branch they have now.

But even if you do nothing…

On October 1, 2020, if you haven’t changed the default branch for new repositories for your user, organization, or enterprise, it will automatically change from master to main.

gix is a command-line interface (CLI) to access git repositories. It’s written to optimize the
user-experience, and perform as good or better than the canonical implementation.

Furthermore it provides an easy and safe to use API in the form of various small crates for implementing your own tools in a breeze.

The author describes this as “idiomatic, modern, lean, fast, safe, & pure” but that was too many superlatives to put in the headline. It does look nice, though. I dig the libraries + CLI that leverages them approach. Demo video on Asciinema.

Built in Go, askgit is an open source CLI and coming soon web interface (linked above). With this tool in your toolbox, you can mine your repo for info like commit count by author on each day of the week:

SELECT
    count(*) AS commits,
    count(CASE WHEN strftime('%w',author_when)='0' THEN 1 END) AS sunday,
    count(CASE WHEN strftime('%w',author_when)='1' THEN 1 END) AS monday,
    count(CASE WHEN strftime('%w',author_when)='2' THEN 1 END) AS tuesday,
    count(CASE WHEN strftime('%w',author_when)='3' THEN 1 END) AS wednesday,
    count(CASE WHEN strftime('%w',author_when)='4' THEN 1 END) AS thursday,
    count(CASE WHEN strftime('%w',author_when)='5' THEN 1 END) AS friday,
    count(CASE WHEN strftime('%w',author_when)='6' THEN 1 END) AS saturday,
    author_email
FROM commits GROUP BY author_email ORDER BY commits

Leading off the updates for Git 2.28 is the highly sought after ability to configure init.defaultBranch so folks can move from master to main as their default branch name.

From Taylor Blau on the GitHub blog:

When you initialize a new Git repository from scratch with git init, Git has always created an initial first branch with the name master. In Git 2.28, a new configuration option, init.defaultBranch is being introduced to replace the hard-coded term. (For more background on this change, this statement from the Software Freedom Conservancy is an excellent place to look).

Starting in Git 2.28, git init will instead look to the value of init.defaultBranch when creating the first branch in a new repository. If that value is unset, init.defaultBranch defaults to master…

Also check out github/renaming to learn more about the complementary changes GitHub is making. GitLab and Bitbucket are making similar changes.

gitqlite is a tool for running SQL queries on git repositories. It implements SQLite virtual tables and uses go-git. It’s meant for ad-hoc querying of git repositories on disk through a common interface (SQL), as an alternative to patching together various shell commands.

Mine your repo’s history for goodies. Here’s how to get commit count by author email:

SELECT author_email, count(*) FROM commits GROUP BY author_email ORDER BY count(*) DESC

From Kabir Nazir on the AltCampus blog:

One of the things a lot of newbie developers overlook often is the format of their commit messages. Properly formatted commit messages can do so much more than just looking neat…

Use the imperative mood(present tense) when framing messages … Think of each commit in your code as a change that is being applied to your codebase.

This makes heavy use of fzf, which is a command-line fuzzy finder. You can stage and unstage files fuzzily found by the tool and commit interactively.

Max Mulatz:

This is a call for solidarity and a love letter to good commit messages. Read this to find out why it’s worth to care about commit messages and how to get better at writing them.

gitpert measures the “pertinence” of git authors as a time-decayed measure of LOC added and removed to a repository (or a set of files in a repository). It’s meant to help identify who the most relevant contributors are based on commit recency, frequency and impact.

Cool tool, as long as we don’t forget about non-code contributors.

Delta provides language syntax-highlighting, within-line insertion/deletion detection, and restructured diff output for git on the command line. All the syntax-highlighting color themes that are available with bat are available with delta. Here’s what git show looks like when git is configured to use delta as its pager:

Written in C++ and powered by Qt 5. #notelectron

David Thompson:

I like Git commit messages. Used well, I think they’re one of the most powerful tools available to document a codebase over its lifetime. I’d like to illustrate that by showing you my favourite ever Git commit.

6-ish paragraphs of explanation for a single whitespace change in the code.

The New Stack takes us on a fun trip down memory lane:

Fifteen years ago a number of the Linux kernel developers tossed their hands in the air and gave up on their version control system, BitKeeper. Why? The man who held the copyright for BitKeeper, Larry McVoy, withdrew free use of his product on claims that one of the kernel devs had reverse engineered one of the BitKeeper protocols.

Linux creator Linus Torvalds sought out a replacement to house the Linux kernel code. After careful consideration, Torvalds realized none of the available options were efficient enough to meet his needs:

In short, I use git branches very rarely, preferring to work on my local master branch almost every time. When I want to work on multiple tasks in the same repository (i.e. often), I just… work on all of them on master. I waste no time creating a new branch, or switching to another branch to change contexts; I just start writing code and committing changes, all directly on master, intermixing different workstreams freely. This reduces my startup time to zero, both for starting new tasks and revisiting old work.

If the blog post ended here, you might think Drew is crazy. But he goes on to explain how he uses rebase to clean things up before pushing upstream.

I enjoy hanging out on master quite a bit, myself. However, when I’m ready to take on something “big” or “gnarly” I don’t hesitate to git checkout -b and work from there.

One of the great things about Git is everyone can develop their own branching strategies. One of the terrible things about Git is everyone has to develop their own branching strategies. In this quick post on the Adeva blog, Vedrana Tozija describes a strategy she believes is on point for small teams.

Patrick DeVivo:

tickgit is a tool for software developers to do project management within their codebase. It searches code comments for markers indicating areas and files worth returning to (TODO, FIXME, etc). It can be used to proactively identify areas of technical debt, or handle day-to-day to-do items and checklists.

Free for public repos and open source.

A handy little web app for quickly finding the droids code you’re looking for.

grep.app searches code from over a half million public repositories on GitHub. We’re hoping to add more soon…

It searches for the exact string you enter, including any punctuation or other characters. You can also search by regular expression, using the RE2 syntax.

GistPad is a Visual Studio Code extension that allows you to manage GitHub Gists entirely within the editor. You can open, create, delete, fork, star and clone gists, and then seamlessly begin editing files as if they were local.

The big idea here is to use gists to seamlessly create your “very own developer library”. The interactive playgrounds is pretty cool, too.

Don’t use this, but do check it out if you want to learn more about how Git works. Or about how POSIX shell works. Or both!