Ask HN: How to Teach Git Rebase | Hacker News Reader

Ask HN: How to Teach Git Rebase

18 pointspoplarstand13 comments

One of the projects I work on has a Git Rebase workflow. Developers looking to get their changes into the main branch:

1. Do a rebase to get their branch in-sync with main, 2. Squash their branch's commits, 3. Make a push/force push to their branch, and 4. Create a pull request.

Which is lovely, but the process has a gnarly learning curve for our junior devs.

Is anyone familiar with documentation or tooling that does a good job of streamlining this sort of workflow?

View on HN

I've had success using https://git-rebase.io/ to help people understand the workflow.

There's some pretty clever tricks on that site that I wasn't familiar with. Much appreciated!

I feel dirty anytime I put '--force' and I encourage workflows that don't mess with history. In every code base I've been in, it is just more straightforward to squash merge smaller, self-contained, commits into your main branch. Tests should act as a gate for committing to the main branch.

I agree. Part of the motivation for this post is that I've been doing triage on a maimed branch that got incorrectly squashed.

That being said, the workflow for this project is unlikely to change. And, to be fair, the workflow has its benefits. The project history is very clean, PR code reviews are straightforward, etc.

What's the point of "clean project history" if junior developers accidentally sometimes break entire branches? You can get "clean views" of history with merge commits with things like --first-parent. Most PR tools today let you look at branch as a whole and it doesn't matter if you squash first or not.

Rebase workflows are so much additional work and the benefits don't actually seem worth that extra work. You can use the tools already available to get most of the same "benefits" and there's a lot less likelihood of needing to do a reflog search or deep dive into squashed commmits with no merge hints left of where a hidden three way merge took the wrong path or a need to manually manage some developer's rerere cache.

I'm biased, of course, by hitting so many of these worst case scenarios and being "the only expert" to get people out of them that I just generally don't trust any workflow that involves junior developers doing lots of unsupervised squashes and rebases. I like merge commits. I like having DAG traversal options when I need them (to fix some junior developer's accidentally bad merge; to archeology my way to deeper context around bugs). Those seem like much better "benefits" than "the project history is clean".

I worked at a place that used this workflow and thought it was incredibly annoying. They also had a bunch of custom git commands set up and "trained" you to use those commands. Many people did not know what they actually did, or how to get themselves out of a jam.

Assuming devs are familiar with the usual branch/commit/push workflow, and history rewrites like rebase/cherry-picking are the point of confusion:

I can't recommend highly enough Learn Git Branching[1], an interactive demo for understanding rebases and cherry-picks.

Then try it a couple of tricky times, and you're settled.

[1]: https://learngitbranching.js.org/

If by any chance you use zsh, oh-my-zsh, and its git plugin, I can offer you this function:

  function stash_and_rebase() {
    local current_branch="$(git_current_branch)"
    if (( ${#current_branch} == 0 )); then
      echo "There is no current branch. This script must be executed in git repo."
      return 1
    fi
    if (( $# == 0 )); then
      local target_branch="$(git_main_branch)"
    else
      local target_branch="$1"
    fi
    git stash push
    git fetch --all
    git rebase origin/${target_branch}
    echo "Don't forget to execute 'git stash pop' after rebase!"
  }

Let's say you want to rebase onto `main`. Checkout your feature branch and run `stash_and_rebase`. If you want to rebase onto non-main branch, run `stash_and_rebase branchX`. If everything went OK, do `git stash pop` in the end.

N.B. This doesn't do squash!

That workflow is a PITA. Junior devs (or even seniors!) are likely to screw that up, lose work, and create even more work untangling mistakes. The fact you need to force push regularly is a sign it should be avoided.

I think visualization is very useful when dealing with this sort of thing, I found this stackoverflow answer: https://stackoverflow.com/a/29916361 very useful, because of the ascii art for visualizing the rebase, and the mnemonic device for each "version" of a rebase (like calling the git rebase --onto w/ 3 arguments "the surgeon")

I guess this might help. The website is designed to help people understand some basic git concepts visually https://onlywei.github.io/explain-git-with-d3/#rebase

I really appreciate the efforts for gitimmersion.com.

https://gitimmersion.com/lab_31.html is likely where you would want to explore. hths!

That is a very cool website that I'd never seen before today. Thank you!

Reply on news.ycombinator.com