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 a