Rebase is easy and not terrifying. Here's a 1k word article on how to do it correctly.
Or just do a merge and move on with your life.
Git Rebase for the Terrified
141–150 of 305 posts
Re: Git Rebase for the Terrified
#142I wish rebase was taught as the default - I blame the older inferior version control software. It’s honestly easier to reason about a rebase than a merge since it’s so linear. Understanding of local versus origin branch is also missing or mystical to a lot of people and it’s what gives you confidence to mess around and find things out
The end result of a git rebase is arguably superior. However, I don't do it, because the process of running git rebase is a complete hassle. git merge is one-shot, whereas git rebase replays commits one-by-one. Replaying commits one-by-one is like a history quiz. It forces me to remember what was going on a week ago when I did commit #23 out of 45. I'm grateful that git stores that history for me when I need it, but…
Then is not rebase your problem, but all your other practices. Long lived feature branches with lot's of unorganized commits with low cohesion.
Sometimes it's ok to work like this, but you asking git not being judgamental is like saying your roomba should accomodate to you didin't asking you to empty it's dust bag.
Re: Git Rebase for the Terrified
#143I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…
> Fundamentally, I do not debug off git history. Are you saying that you've never used git bisect? If that's the case, I think you're missing out.
Git bisect is a wonder, especially combined with its ability to potentially do the success/fail testing on its own (with the help of some command you provide).
It is a tragedy that more people don't know about it.
Re: Git Rebase for the Terrified
#144Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement. In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained t…
Does it support submodules yet? That was the thing that stopped me using it last time I checked.
Not natively, but you can still use the regular git commands to update them, and it works.
Re: Git Rebase for the Terrified
#145Rebase is easy and not terrifying. Here's a 1k word article on how to do it correctly. Or just do a merge and move on with your life.
If you want to have a linear history on main, either always rebase your branch onto main, or merge but only accept squashed commits onto main.
Re: Git Rebase for the Terrified
#146I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…
If you haven't used git bisect to find a regression, you should try it. You can write a test (outside of source control) and run `git bisect good` on a good commit and `git bisect bad` on bad one and it'll do a binary search (it's up to you to rerun your test each time and tell git whether that's a good or a bad commit). Rather quickly, it'll point you to the commit that caused the regression. If you rebase, that com…
> it's up to you to rerun your test each time and tell git whether that's a good or a bad commit
not true. You can use
git bisect run script-command arguments
Re: Git Rebase for the Terrified
#147I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…
I manage a maintained fork and periodically rebase our changes on top of upstream. In this case, rebasing is nice because our changes stay in a contiguous block at the top (vs merging which would interleave them), so it's easy for me and others to see exactly where our fork diverges.
Doesn’t that mean you have to fix all the merge conflicts introduced by your commits on every rebase though?
Re: Git Rebase for the Terrified
#148Earlier quoted context omitted.
But it's at best much harder to find stuff in the reflog than to simply use git's history browsing tools. "What's the state of my never-rebased branch at time X" is a trivial question to answer. Undoing a rebase, at best, involves some hard resets or juggling commit hashes. None of it is impossible, but IMHO it's a lot of excitement of the wrong kind for essentially no reward.
> "What's the state of my never-rebased branch at time X" is a trivial question to answer. Yes, but only because of reflog.
git log will also do the job, even if you never checked out the branch in this workspace.
Re: Git Rebase for the Terrified
#149I don't understand why I would push to origin my local branch. This will (potentially) require multiple push -f. I prefer to share the work in a state I considere complete.
As an alternative, just create a new branch! `git branch savepoint-pre-rebase`. That's all. This is extremely cheap (just copy a reference to a commit) and you are free to play all you want.
You are a little more paranoid? `git switch -c test-rebase` and work over the new branch.
Re: Git Rebase for the Terrified
#150Earlier quoted context omitted.
> I can give you an example of when I am glad I rebased I think the question was about situations where you were glad to rebase, when you could have merged instead
They kind of spoke to it. Rebasing to bring in changes from main to a feature branch which is a bit longer running keeps all your changes together. All the commits for your feature get popped on top the commits you brought in from main. When you are putting together your PR you can more easily squash your commits together and fix up your commit history before putting it out for review. It is a preference thing for su…
i don't think i have ever even looked at what order the commits are, i only care about the diff vs the target branch when reviewing
especially since every developer has a different idea of what a commit should be, with there being no clear right answer