Git

Some code is broken, and you can’t figure out why. Maybe there are a lot of changes, and identifying the breaking change seems impossible. Or, maybe you’re curious about how things break in your organization. The tool you need is git-bisect. Git bisect conducts a binary search through your Git history to find a commit of interest. In this post, I’ll show how it works. A Caveat: Atomic Commits Required For bisect to be useful, you must be committing atomically. If your practice is to squash-merge PRs, or commit swaths of unrelated code with each commit, a bisect may only tell you that something broke when you merged in a huge PR. That can be, isn’t always, useful information. ...

You’ve been working on a big set of changes, and haven’t committed to Git yet. Now, you want to commit some, but not all, changes to a file. Let’s look at adding patches. Here’s the command. $ git add --patch --patch lets you interactively choose which changes to apply to a commit. Applying Patches Run this command and you’ll see the following: $ git add --patch diff --git a/README.md b/README.md index 18d277a..b012031 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,7 @@ # [jakeworth][production-url] +A blog of awesome Git tricks. + (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? ? This is a piece of our diff, or a ‘hunk’, with information telling us which one we are currently reviewing (one of two), and a menu of options. ...

When I rebase, I force-push altered history using the flag --force-with-lease instead of the commonly-used --force. git push --force-with-lease But why? This is a TIL for me because I’ve used this command for years without reading the docs. Take it away, docs: This option allows you to say that you expect the history you are updating is what you rebased and want to replace. If the remote ref still points at the commit you specified, you can be sure that no other people did anything to the ref. ...

I’m working on a team where we keep a clone of the development branch (the main place where work is done), used to deploy to a QA environment. The benefits of this branching technique are: clone is isolated from work It’s easy to tell what was deployed to QA– clone is the source of truth Instead of merging, we just reset clone to match the development branch. Here’s the technique: ...

Last week, I started a new project: porting Today I Learned from Ruby on Rails to Phoenix (Elixir). The first few commits were pair programmed with Josh Branchaud, and I hope to work with him and other Rocketeers going forward. The repo for the new codebase is here. There’s a lot of work to do to reproduce even the MVP functionality of TIL. We’re using the ‘Projects’ feature of Github to track progress right in the repo. ...

Many pull requests go through a cycle: programmer opens pull request, maintainer gives feedback, programmer makes changes, repeat until ready to merge, maintainer merges. Prior to the merge, the pull request can be messy, full of reverts, fixups, and WIP commits. In the end, those commits are noise. We can tell a better story by squashing the branch. Consider this Git branch history: * 724d574 (HEAD -> issue/38) Good to merge! * e2af5ac Refactoring the previous commit * 3e36475 Test are passing here * ea479cb Revert "Ooops" * 77aee1d Ooops * 4c7ead2 Test breaker The final commit at the top, 724d574, has been approved to merge by the maintainer. But this branch is a mess. We have a commit that’s just refactoring (e2af5ac), two commits that cancel each other out (ea479cb and 77aee1d), and one that has failing tests (4c7ead2). ...

Tagging releases with Git is a good idea. In case your tags get off track, here is how you delete a Git tag locally and on a remote: $ git tag -d abc $ git push origin :refs/tags/abc To git@github.com:hashrocket/hr-til - [deleted] abc It gets trickier if you’re using Semantic Versioning, which includes dots in the tag name. The above won’t work for v16.0.0. This will: $ git tag -d v16.0.0 $ git push origin :v16.0.0 To git@github.com:hashrocket/hr-til - [deleted] v16.0.0

In my never-ending quest to better summarize my work at the end of the day using computers, I discovered today the Git --author flag. It works like this: $ glg --since=midnight --author=dev+jwworth+mikechau@hashrocket.com * 4ba91a8 (HEAD, origin/checkout, checkout) Add guard for manual entry of employee discount * 3a4e4c9 Seed a coupon and code and auto-apply in preview * cb1adee Add discount ... The alias glg is discussed here. I use this when multiple developers or teams are committing throughout the day to the same repository, to disambiguate our work from others. Ready to paste into your billing software of choice.

I like to read commit logs. Today I wanted to see the first commit on a project. Here’s what I used: git rev-list --max-parents=0 HEAD Show me the commits that led to HEAD in reverse chronological order; then limit that list to the commits with no parent. Here’s a small modification, to show the entire commit rather than the SHA alone: git show $(git rev-list --max-parents=0 HEAD)

At the end of each day, I try to record what I did, to jog my memory during the next morning’s standup. This is a helpful aid: git log --since="24 hours ago" I SSH into my work machine and run this in my project’s root directory. Combined with an alias from the Hashrocket Dotmatrix, glg (git log --graph --oneline --decorate --color --all), I get a terse summary of the day’s work, ready to be pasted into your note-taking or project management tool of choice: ...