Don't use Git rebase
medium.com
Don't use Git rebase
1–10 of 88 posts
Re: Don't use Git rebase
#2What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing.
Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity to revisit conclusions from debugging or experiments.
You can also use merge commits to describe sub-units of work in your feature branch. Just rename your branch to some subtask and merge that into your feature branch.
edit: towards the middle of the article, the author also opines "What motivates people to rebase branches? ... I’ve come to the conclusion that it’s about vanity. Rebasing is a purely aesthetic operation. The apparently clean history appeals to us as developers, but it can’t be justified, from a technical nor functional standpoint."
Re: Don't use Git rebase
#3Doesn't squash and rebase eliminate this problem? It removes all those possibly broken intermediate commits once it's in master.
I'll add that another annoying thing about rebasing is that if you make multiple changes to the same piece of code that conflict with changes on master, when you rebase, you have to resolve each change independently instead of only the last snapshot. However, if the changes are in different places, I like the incremental conflict resolution process of rebasing instead of the one-shot merge commit.
Re: Don't use Git rebase
#4There is a third option nobody seems to talk about `git merge --squash` (a squashed commit bundles commits into one commit). Which produces like `rebase` a linear commit history, but preserves the single commits.
Re: Don't use Git rebase
#5[deleted]
Re: Don't use Git rebase
#6What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing. Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity…
The main use case for rebase for me is to add automatic rebases on pull to the git config.
Normally if you pull from the remote and have local commits not in the remote, you'll have an "extra" merge. Automatic rebase on pull takes care of this, to avoid those useless merges.
Re: Don't use Git rebase
#7What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing. Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity…
Rebase is often required by open source projects. It makes that a few commits, once integrated, look like they are made directly on top of master instead of merged.
Re: Don't use Git rebase
#8What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing. Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity…
Periodic merges in which nothing interesting is happening are just useless cruft. Just spam the Git history.
Re: Don't use Git rebase
#9What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing. Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity…
The main use case for rebase for me is to add automatic rebases on pull to the git config. Normally if you pull from the remote and have local commits not in the remote, you'll have an "extra" merge. Automatic rebase on pull takes care of this, to avoid those useless merges.
Surely our tools should simply have an option of hiding useless merges. It's a display problem not a reason to change history.
Re: Don't use Git rebase
#10Doesn't squash and rebase eliminate this problem? It removes all those possibly broken intermediate commits once it's in master. I'll add that another annoying thing about rebasing is that if you make multiple changes to the same piece of code that conflict with changes on master, when you rebase, you have to resolve each change independently instead of only the last snapshot. However, if the changes are in different…
You can have git remember the previous conflict resolutions and automatically apply them the next time you rebase the same code by setting git config --global rerere.enabled true
It’s a builtin feature, see the documentation https://git-scm.com/docs/git-rerere and a description here: https://git-scm.com/blog/2010/03/08/rerere.html
Very handy if you use rebase with multiple commits to the same code.