WingNews logo WingNews
top | item 32097443

Ask HN: How to Teach Git Rebase

18 points| poplarstand | 3 years ago

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?

13 comments

order

nprescott|3 years ago

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

poplarstand|3 years ago

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

sethammons|3 years ago

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.

poplarstand|3 years ago

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.

FrenchyJiby|3 years ago

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/

ivanche|3 years ago

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!

icedchai|3 years ago

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.

oshirisuki|3 years ago

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")