Git

Every day working with git we create Pull Requests (PRs). This process is the bread and butter of collaboration with git: forking a repository, creating a branch to implement a fix and then sending a PR to the maintainer. For example see the GitHub Docs: Creating a pull request from a fork. The other day I came across a slightly different case - contributing to someone else’s in-progress pull request. They had a branch open on their own fork of a project - and the change I wanted to send was for content only on that branch. Git supports this process (in fact the every-day case is just a specific example where the PR is to the core repository and the target branch is main). GitHub also provides tools to support this process, but the workflow is a little different from the every-day case because both the base and the head of the PR need to be set away from their usual defaults. ...

You’re staring at a bug that definitely wasn’t there six months ago. The codebase has hundreds of commits since then. You could read through every one looking for the culprit - or you could let git bisect find it for you in five steps. git bisect performs a binary search through your commit history. You tell it one good commit and one bad commit, and it checks out the midpoint for you to test. You say “good” or “bad”, it halves the range again (running a binary search) and in no time it tells you exactly which commit introduced the problem. ...

With all the best intentions in the world sometimes commit-logs are skipped or entered in haste - a brief short-term gain for long-term pain and future-you (or worse someone else) feeling rightly peeved with you. For personal repositories the temptation to quickly type “notes” / “comments” etc. can be even stronger and once the commits are made you probably wont be thinking about them again until you need to (enter peeved future self). ...