git rebase is really nice. Can recommend it to clean up a git history :D

I never understood the need to clean your history.

If you use git add -p your history is always clean.

@sariel What’s the p flag for? (She says, clearly too lazy to Google)

@sariel Mostly agreed

Some people prefer having a single commit per feature. I disagree with them as it loses history and context.

But sometimes I do something silly like commit on the wrong branch and don’t want to preserve the revert commit.

@AmyShackles git add --patch

It allows you to stage sections of code at a time (and edit those sections to include or exclude individual lines). It’s so useful that it’s my default now!

Git rebase is the minimum requirement as working with branches leads to ugly tumbleweeds when merging without rebasing first.

But if you actually need to clean the history (maybe someone pushed some huge asset sources or passwords), filter-branch is what you need.

1 squash merge per story. Keeps things simple. If the merge is too big then perhaps the story is too big.

Newbie here, what situations is git rebase useful for?

I use it for pulling, but I've had problems using it with different branches that were multiple commits apart.

@tobb10001 rebase is nice to avoid merge conflicts, cause basically you're applying the alterations you made on top of a more updated code than the one you used as the base. it's almost like creating a stash, doing a pull and popping, but with something that is already committed (could be one or more commits).
of course, you have to do that locally, you can't go doing that stuff directly on a shared repo.

@tobb10001 Git rebase can be really risky, it can overwrite parts of your history without a trace if you're not careful, especially when the history of the base branch has significantly evolved.
Therefore, don't rebase from the master/main branch. Rebase on a side branch, test and, only then merge (fast forward) with main/master. Luckily there is still git reset just in case

@Crost
Every time where you want to keep commits separated, rebase + merge is better than squash + merge. Wanting to merge multiple commits happens often for me.

Also, i keep my feature branches fresh by rebasing them every day, so there will be no surprises when i do the final pre-push tests.

Sometimes i get distracted and end up with multiple unrelated fixes and refactorings next to some actual feature progress. Then i can checkout staging, cherry-pick non-feature stuff, push that stuff, create a new temporary branch, cherry-pick the remainder from the feature branch, checkout the feature branch, hard reset to the last commit common to staging, merge-in the temporary branch, delete the temporary branch and everything is neat and tidy with a reasonable effort (really sounds way more than it actually is).
Ideally i would be well-focused on task and note the distractions for later. But that aint gonna happen and GIT doesn't judge...