121–130 of 305 posts
I 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
I 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 have often been happy to have a clean linear history when asking myself things like "does build X.Y.Z include this buggy change I found in commit abcdefg?". With a history full of merges, where a commit from 1st of January might be merged only on the 20th of July, this gets MUCH harder to answer. This is especially true if you have multiple repos and builds from each one, such that you can't just checkout the commi…
>the worst case scenario for a rebase gone wrong is that you delete your local clone and start over. Wouldn't it be enough to simply back up the branch (eg, git checkout -b current-branch-backup)? Or is there still a way to mess up the backup as well?
Yeah, deleting your local clone and starting over should normally not be necessary, unless you really mess things up badly. The "local backup branch" is not really needed either because you can still reference `origin/your-branch` even after you messed up a rebase of `your-branch` locally. Even if you force-pushed and overwrote `origin/your-branch` it's most likely still possible to get back to the original state of…
Allow 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…
I see no need to ever rebase manually, just merge on your branch and always fast-forward squash merge (only sane default) with GitHub/GitLab/whatever.
Don't erase history. Branch to a feature branch, develop in as many commits as you need, then merge to main, always creating a merge commit. Oftentimes, those commit messages that you're erasing with a squash are the most useful documentation in the entire project.
Earlier quoted context omitted.
> I know a lot of people want to maintain the history of each PR, but you won't need it in your VCS. Having worked on a maintenance team for years, this is just wrong. You don't know what someone will or won't need in the future. Those individual commits have had extra context that have been a massive help for me all sorts of times. I'm fine with manually squashing individual "fix typo"-style commits, but just squash…
Disagree! If those commits were ready for production, they would have been merged. ;) Don't put a commit on main unless I can roll back to it.
PSA: I’m not terrified of rebase, yet it’s good to know this: https://docs.github.com/en/get-started/using-git/about-git-r... > Warning - Because changing your commit history can make things difficult for everyone else using the repository, it's considered bad practice to rebase commits when you've already pushed to a repository. A similar warning is in Atlassian docs.
Is there a reason why that recommendation cannot be changed to "don't ever force push unless you are certain no one else has fetched this branch"?
I 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…
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.
Earlier quoted context omitted.
> Just go back in time and get a snapshot of what the repo looked like 2 weeks ago. Ah. Except rebase. This is false. Any googling of "git undo rebase" will immediately point out that the git reflog stores all rebase history for convenient undoing. Shockingly, got being a VCS has version control for the... versions of things you create in it, not matter if via merge or rebase or cherry-pick or whatever. You can of co…
Up to a point - they are garbage collected, right? And anyway, I don't want to dig this deep in git internals. I just want my true history. Another way of looking at it is that given real history, you can always represent it more cleanly. But without it you can never really piece together what happened.