Ask HN: How to Teach Git Rebase

18 points by poplarstand 3 years ago | 13 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?

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.

WorldMaker 3 years ago | | |

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

icedchai 3 years ago | | |

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.

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

0xankit 3 years ago |

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

normalhappy 3 years ago |

I really appreciate the efforts for gitimmersion.com.

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

poplarstand 3 years ago | |

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