Git from the Bottom Up – Rebasing

It’s time to understand the full power of Git’s rebase capabilities while Allen takes a call from Doc Brown, Michael is breaking stuff all day long, and Joe must be punished.

The full show notes for this episode are available at https://www.codingblocks.net/episode193.

News

• Thanks for the review Itsamritchahal!
  • Want to help out the show? Leave us a review!
• Ludum Dare is a bi-annual game jam that’s been running for over 20 years now. Jam #51 is coming up September 30th to October 3rd. (ldjam.com)
  • We previously talked about Ludum Dare in episode 146.

Branching and the power of rebase

• Every branch you work in typically has one or more base commits, i.e. the commits the branch started from.
• git branch shows the branches in your local repo.
• git show-branch shows the branch ancestry in your local repo.
  • Reading the output from the bottom up takes you from oldest to newest history in the branches
  • Plus signs, are used to indicate commits on divergent branches from the one that’s currently checked out.
  • An asterisk, is used to indicate commits that happened on the current branch.
  • At the top of the output above the dashed line, the output shows the branches, the column and color that will identify their commits, and the label used when identifying their commits.
• Consider an example repo where we have two branches, T and F, where T = Trunk and F = Feature and the commit history looks like this:

• What we want to do is bring Feature up to date with what’s in Trunk, so bring T2, T3, and T4 into F3.
  • In most source control systems, your only option here is to merge, which you can also do in Git, and should be done if this is a published branch where we don’t want to change history.
  • After a merge, the commit tree would look like this:

• The F3' commit is essentially a “meta-commit” because it’s showing the work necessary to bring T4 and F3 together in the repository but contains no new changes from the working tree (assuming there were no merge conflicts to resolve, etc.)
  • If you would rather have your work in your Feature branch be directly based on the commits from Trunk rather than merge commits, you can do a git rebase, but you should only do this for local development.
  • The resulting branch would look like this:

• You should only rebase local branches because you’re potentially rewriting commits and you should not change public history.
  • When doing the merge, the merge commit, F3' is an instruction on how to transform F3 + T4.
  • When doing the rebase, the commits are being rewritten, such that F1' is based on T4 as if that’s how it was originally written by the author.
• Use rebase for local branches that don’t have other branches off it, otherwise use merge for anything else.

Interactive rebasing

• git rebase will try to automatically do all the merging.
• git rebase -i will allow you to handle every aspect of the rebase process.
  • pick – This is the default behavior when not using -i. The commit should be applied to its rewritten parent. If there are conflicts, you’re allowed to resolve them before continuing.
  • squash – Use this option when you want to combine the contents of a commit into the previous commit rather than keeping the commits separate. This is useful for when you want multiple commits to be rewritten as a single commit.
  • edit – This will stop the rebasing process at that commit and let you make any changes before doing a git rebase --continue. This allows you to make changes in the middle of the process, making it look like the edit was always there.
  • drop – Use when you want to remove a commit from the history as if it had never been committed. You can also remove the commit from the list or comment it out from the rebase file to get the same results. If there were any commits later that depended on the dropped commit, you will get merge conflicts.
• Interactive gives you the ability to reshape your branch to how you wish you’d done it in the first place, such as reordering commits.

Resources we Like

• Git from the Bottom Up by John Wiegley (jwiegley.github.io)
  • Branching and the power of rebase (jwiegley.github.io)
  • Interactive rebasing (jwiegley.github.io)
• Site Reliability Engineering – Embracing Risk (episode 182)

Tip of the Week

• Russian Circles is a rock band that makes gloomy, mid-tempo, instrumental music that’s perfect for coding. They just put out a new album and, much like the others, it’s great for coding to! (YouTube)
• GitLens for Visual Studio Code is an open-source extension for Visual Studio Code that brings in a lot more information from your Git repository into your editor. (marketplace.visualstudio.com)
  • Also mentioned in episode 79 and episode 149.
• Configure Visual Studio Code as your Git editor. (coding.visualstudio.com)
• JSON Crack is a website that makes it easy to “crack” JSON documents and view them hierarchically. Great for large docs. Thanks for the tip Thiyagu! (JsonCrack.com)
• Handle is a Windows utility that you can use to see which process has a “handle” on your resource. Thanks for the tip Larry Weiss! (docs.microsoft.com)
• Crunchy Data has made it so you can run PostgreSQL in the browser thanks to WASM. Technically very cool, and it’s a great way to learn Postgres. Thanks for the tip Mikerg! (Crunchy Data)
• Divvy is a cool new window manager for macOS. It’s cool, modern, and much more powerful than the built in manager! Thanks for the tip jonasbn! (apps.apple.com)

Episode source