Most of the comments to my recent articles on 3 Git commands I use every day and When to make a Git commit have mentioned using git rebase.
So, le...
For further actions, you may consider blocking this person and/or reporting abuse
Just remember to always
git branch backupbefore you rebase. Then, after the rebase, you cangit diff backupto make sure it went well. If something does go awry, you can justgit reset --hard backupand start over.There's no need to create a backup branch. You can do
git diff HEAD@{N}~rangeandgit reset --hard HEAD@{N}. Also seegit reflogI agree. But from my experience, people just learning how to rebase really don't want to know anything about
git reflog.The branch method is simpler for beginners.
You can also use
git commit --fixup <hash>to prepare a fixup (or squash using --squash). They will be added on top of your branch so you still have to do a rebase usinggit rebase -i --autosquashto do the fixup or squash. I use this a lot to quickly fix PR review comments or mistakes I made along the way.git commit --amend --no-editis also useful in such cases, which simply adds your changes to previous commit,
Yup, but that only goes for the last commit whereas a fixup can blend into any commit after a rebase.
Really neat, I didn't understand initially what it is
Very useful when you're using cli to commit with a message, but the commit message turns out too long so you shorten it, then can go to --amend --no-edit to extrapolate on the initial brief commit message. This is my most common use for this.
My second is forgetting to mention a change in a commit.
git reflogworks, but finding the original pre-rebase ref in the mass of reflog output that occurs during a rebase disaster can be difficult, especially for beginners.I find it way easier to just create a backup branch, giving you an easily, visible "last good" ref you can quickly reset to. After all - this is git, branches are cheap!
In the stale branch example, using the video editing metaphor, do the dates of commits on the base and branch influence how the branch merge is done? Do newer base commits get applied after older branch commits?
No, the commit dates do not influence a rebase. The base branch commits are fast forwarded, then the stale branch commits are replayed.
Techically a replayed commit creates a new commit. So it has a new SHA and time stamp, and everything else is the same.
I agree that it is a much cleaner approach than merging feature branches into master (and master back into the feature branch to get changes from other branches and developers) and as well that squashing and rebasing helps to keep the history of master clean, e. g. by squashing work unit and WIP commits into a single or few feature commits on master. I found this post via How I Git, so my question might relate to that post as well.
But I have one caveat with this workflow:
How do I rebase my feature branch on top of master to get rid of it's stale status when it is remote tracked on GitHub or GitLab? And there are mainly three reasons to remote track a feature branch and regularly push it:
Try
--ontoas well, it's pretty neat. It allows you to rebase on a changed base branch (e.g. when the base has rebased itself).Thanks for this!
Thanks a lot, Jason. This is my guide, moreover man pages.
Thanks for sharing the knowledge :)