Git Rebase vs Merge
The cluster centers on debates about using git rebase versus merging in version control workflows, highlighting benefits like cleaner commit history and drawbacks such as rewriting shared history and conflict resolution challenges.
Activity Over Time
Top Contributors
Keywords
Sample Comments
GitHub/Gitlab allow you to rebase your commits when merging. We do that, but has the disadvantage of mucking up things for people who are using that commit. I personally think it’s worth it
why do people rebase so often? shouldn't it be excluded from the usual workflows as you are losing commit history as well?
There's More Than One Way To Do It. Some people find rebase more convenient, some people cherry-pick commits onto another branch, or squash merge them into another branch and merge that into master. Or whatever. Git is fast and powerful in part because it's really stupid. Building another layer of "meta-history" into git would complicate things immensely.
It’s exactly like merging but you have to resolve any conflicts commit-by-commit instead of all at once in a merge commit. Useful for if you’ve been working on a feature and want to pull in changes your colleagues have made on the develop or master branch without muddying up your history with merge commits. Having clean history makes diffing easier for code reviews. I’ll admit even after years of rebasing, I still screw it up from time to time.
Rebase is a lot more than a merge strategy. Merging is only one of the things it can do. Rebase -i allows you to rewrite history, and if you rewrite history of shared code, it leads to all sorts of issues with git.
Well, that's what we have git rebase for.
As a git newbie I just do git pull. Is the problem that the merge makes the commit history harder to reason through in the future vs if you rebase?
Using a rebase to update from master will cause conflicts for anyone else working on the PR branch. To understand why, imagine a developer branches from master at commit A, and then creates two commits on the branch B and C. In the meantime, master gets updated with commits D and E. Rebasing in this situation, results in a branch that looks like A, D, E, F, G, where F and G contain the same content as B and C, but are now tracked under different hashes. If a collaborator has this branch, git wil
Also, use git rebase instead of merge.
Rebase is polite, imho. You probably want a pull request that is "clean" for the code reviewers. And future bug chasers. A bunch of interleaved commits makes it harder for anyone to reason about the code history.