Once a commit cements itself in git’s history—that’s it. It’s impossible to amend a commit message buried deep in a repo’s log.

But git notes enable you to amend new information about old commits in a special namespace. And they’re capable of so much more.

Notes stow metadata about anything tracked by git—any object: commits, blobs, and trees. All without futzing with the object itself.

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

GitHub is the go-to place to host your open source projects, that much is well known. A lot of companies also use their paid plans to get the ecosystem around GitHub for their own code. Why would you want to use anything else? We took the decision to move away from GitHub and in the end we benefitted hugely!

Acts as a proxy for incoming webhooks between your Git hosting provider and your continuous integration server.

When a Git commit webhook is received, the repository in question will be mirrored locally (or updated, if it already exists), and then the webhook will be passed on to your CI server, where it can start a build, using the up-to-date local mirror.

This tutorial demonstrates how to apply changes made to a project hosted in one git repository onto a completely separate project in a different git repository: essentially, merging changes between two totally separate git repositories. If you don't use git, this will likely not interest you much.

A command-line tool that helps you clean up Git branches that have been merged into master.

In this post, I'm going to take a look at some common scenarios where you might want to "undo" a change you've made and the best way to do it using Git.

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day - often several times a day. We can do so through our chat room robot, which is the same place our CI results are displayed. We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it.

There are a number of advantages to deploying so regularly. If you deploy every few hours, it’s almost impossible to introduce large numbers of big bugs. Little issues can be introduced, but then they can be fixed and redeployed very quickly. Normally you would have to do a ‘hotfix’ or something outside of the normal process, but it’s simply part of our normal process - there is no difference in the GitHub flow between a hotfix and a very small feature.

The BFG is a simpler, faster alternative to git-filter-branch for cleansing bad data out of your Git repository history:

* Removing Crazy Big Files * Removing Passwords, Credentials & other Private data

The hub subcommand for git, allows you to perform many of the operations made available by GitHub's v3 REST API, from the git commandline command.

You can fork, create, delete and modify repositories. You can get information about users, repositories and issues. You can star, watch and follow things, and find out who else is doing the same. The API is quite extensive. With this command you can do many of your day to day GitHub actions without needing a web browser.