6 ms·

Ask HN: How to Teach Git Rebase

18 points by poplarstand 4y 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?

normalhappy 4y ago
I really appreciate the efforts for gitimmersion.com. https://gitimmersion.com/lab_31.html https://gitimmersion.com/lab_31.html is likely where you would want to explore. hths!
- poplarstand 4y ago
  That is a very cool website that I'd never seen before today. Thank you!
nprescott 4y ago
I've had success using https://git-rebase.io/ https://git-rebase.io/ to help people understand the workflow.
- poplarstand 4y ago
  There's some pretty clever tricks on that site that I wasn't familiar with. Much appreciated!
ivanche 4y 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!
oshirisuki 4y ago
I think visualization is very useful when dealing with this sort of thing, I found this stackoverflow answer: https://stackoverflow.com/a/29916361 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")
sethammons 4y 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 4y 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 4y 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 4y 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 4y 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/ https://learngitbranching.js.org/
icedchai 4y 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.
0xankit 4y 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 https://onlywei.github.io/explain-git-with-d3/#rebase

18 points by poplarstand 4y ago

normalhappy 4y ago

I really appreciate the efforts for gitimmersion.com. https://gitimmersion.com/lab_31.html https://gitimmersion.com/lab_31.html is likely where you would want to explore. hths!

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

nprescott 4y ago

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

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

ivanche 4y 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!

oshirisuki 4y ago

I think visualization is very useful when dealing with this sort of thing, I found this stackoverflow answer: https://stackoverflow.com/a/29916361 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")

sethammons 4y 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 4y 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 4y 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 4y 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 4y 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/ https://learngitbranching.js.org/

icedchai 4y 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.

0xankit 4y 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 https://onlywei.github.io/explain-git-with-d3/#rebase