I think this is a fake quote that somebody made up for an Internet comedy bit, since it seems unlikely for Hollywood actress Sydney Sweeney to have such uncharacteristically strong opinion on software version control, of all things.
Because she of all people would know that there isn’t anything wrong with using
git merge, and it ultimately comes down to personal preference to what you are used to.Fair point, Margot Robbie
That’s esteemed Academy Award nominated character actress Margot Robbie to you!
She’s modest too!
“Don’t always trust what you read on the internet.”
- Benjamin Franklin
Wait a second, there wasn’t even any social media sites back when Benjamin Franklin lived. Did he write that in his newsletter or something?
I think he was a senior contributor for the underground cracker mag 1600 back in the late 80s.
They called em zines.
Truly he was ahead of his time.
Margot Robbie, I was about to agree with you and thought that was a very reasonable take, until you tried to argue that
git mergeis better thangit rebase, then I simply had to disregard the whole thing.This is why Sydney Sweeney isn’t on Lemmy.
She probably is, just anonymous. It would be crazy to expect anyone to post on lemmy under their real name.
I think this is a fake quote that somebody made up for an Internet comedy bit
You can tell by the pixels
Why is anyone using X in 2024?
I do, I have yet to switch to Wayland
It’s called Twitter now, by conservation of names. /s
Imagine rewring history
ITT: people who have no idea how rebasing works.
Skill issue tbh
No doubt.
git rebaseis like a very sharp knife. In the right hands, it can accomplish great things, but in the wrong hands, it can also spell disaster.As someone who HAS used it a fair amount, I generally don’t even recommend it to people unless they’re already VERY comfortable with the rest of git and ideally have some sense of how it works internally.
Yeah it is something people should take time to learn. I do think its “dangers” are pretty overstated, though, especially if you always do
git rebase --interactive, since if anything goes wrong, you can easily get out withgit rebase --abort.In general there’s a pretty weird fear that you can fuck up git to the point at which you can’t recover. Basically the only time that’s really actually true is if you somehow lose uncommitted work in your working tree. But if you’ve actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.
You can get in some pretty serious messes, though. Any workflow that involves force-pushing or rebasing has the potential for data loss… Either in a literally destructive way, or in a “Seriously my keys must be somewhere but I have no idea where” kind of way.
When most people talk about rebase (for example) being reversible, what they’re usually saying is “you can always reverse the operation in the reflog.” Well yes, but the reflog is local, so if Alice messes something up with her rebase-force-push and realizes she destroyed some of Bob’s changes, Alice can’t recover Bob’s changes from her machine-- She needs to collaborate with Bob to recover them.
Pretty much everything that can act as a git remote (GitHub, gitlab, etc.) records the activity on a branch and makes it easy to see what the commit sha was before a force push.
But it’s a pretty moot point since no one that argues in favor of rebasing is suggesting you use it on shared branches. That’s not what it’s for. It’s for your own feature branches as you work, in which case there is indeed very little risk of any kind of loss.
Ah, you’ve never worked somewhere where people regularly rebase and force-push to master. Lucky :)
I have no issue with rebasing on a local branch that no other repository knows about yet. I think that’s great. As soon as the code leaves local though, things proceed at least to “exercise caution.” If the branch is actively shared (like master, or a release branch if that’s a thing, or a branch where people are collaborating), IMO rebasing is more of a footgun than it’s worth.
You can mitigate that with good processes and well-informed engineers, but that’s kinda true of all sorts of dubious ideas.
Pushing to master in general is disabled by policy on the forge itself at every place I’ve worked. That’s pretty standard practice. There’s no good reason to leave the ability to push to master on.
There’s no reason to avoid force pushing a rebased version of your local feature branch to the remote version of your feature branch, since no one else should be touching that branch. I literally do this at least once a day, sometimes more. It’s a good practice that empowers you to craft a high-quality set of commits before merging into master. Doing this avoids the countless garbage
fix typocommits (and spurious merge commits) that you’d have otherwise, making both reviews easier and giving you a higher-quality, more useful history after merge.
If “we work in a way that only one person can commit to a feature”, you may be missing the point of collaborative distributed development.
No, you divide work so that the majority of it can be done in isolation and in parallel. Testing components together, if necessary, is done on integration branches as needed (which you don’t rebase, of course). Branches and MRs should be small and short-lived with merges into master happening frequently. Collaboration largely occurs through developers frequently branching off a shared main branch that gets continuously updated.
Trunk-based development is the industry-standard practice at this point, and for good reason. It’s friendlier for CI/CD and devops, allows changes to be tested in isolation before merging, and so on.
I know this is a meme post, but can someone succinctly explain rebase vs merge?
I am an amateur trying to learn my tool.
Merge keeps the original timeline. Your commits go in along with anything else that happened relative to the branch you based your work off (probably
main). This generates a merge commit.Rebase will replay all the commits that happened while you were doing your work before your commits happen, and then put yours at the HEAD, so that they are the most recent commits. You have to mitigate any conflicts that impact the same files as these commits are replayed, if any conflicts arise. These are resolved the same way any merge conflict is. There is no frivolous merge commit in this scenario.
TlDR; End result, everything that happened to the branch minus your work, happens. Then your stuff happens after. Much tidy and clean.
Thanks for the explanation. It makes sense. To my untrained eyes, it feels like both merge and rebase have their use. I will try to keep that in mind.
Never use rebase for any branch that has left your machine (been pushed) and which another entity may have a local copy of (especially if that entity may have committed edits to it).
Merge gives an accurate view of the history but tends to be “cluttered” with multiple lines and merge commits. Rebase cleans that up and gives you a simple A->B->C view.
Personally I prefer merge because when I’m tracking down a bug and narrow it down to a specific commit, I get to see what change was made in what context. With rebase commits that change is in there, but it’s out of context and cluttered up with zillions of other changes from the inherent merges and squashes that are included in that commit, making it harder to see what was changed and why. The same cluttered history is still in there but it’s included in the commits instead of existing separately outside the commits.
I honestly can’t see the point of a rebased A->B->C history because (a) it’s inaccurate and (b) it makes debugging harder. Maybe I’m missing some major benefit? I’m willing to learn.
I prefer to rebase as well. But when you’re working with a team of amateurs who don’t know how to use a VCS properly and never update their branc with the parent branch, you end up with lots of conflicts.
I find that for managing conflicts, rebase is very difficult as you have to resolve conflicts for every commit. You can either use rerere to repeat the conflict resolution automatically, or you can squash everything. But when you’re dealing with a team of Git-illiterate developers (which is VERY often the case) you can either spend the time to educate them and still risk having problems because they don’t give a shit, or you can just do a regular merge and go on with your life.
Those are my two cents, speaking from experience.
I agree that merge is the easier strategy with amateurs. By amateurs I mean those who cannot be bothered to learn about rebase. But what you really lose there is a nice commit history. It’s good to have, even if your primary strategy is merging. And people tend to create horrendous commit histories when they don’t know how to edit them.
Honestly, I’m pretty sure 99.9% of git users never really bother with the git history in any way that would be hindered by merging.
Git has a ton of powerful features, but for most projects they don’t matter at all. You want a distributed consensus, that’s it. Bothering yourself with all those advanced features and trying to learn some esoteric commands is frankly just overhead. Yes, you can solve great problems with them, but these problems almost never occur, and if they do, using the stupid tools is faster overall.
How others are keeping their branches up to date is their problem. If you use Gitlab you can set up squash policy for merge requests. All the abomination they’ve caused in their branch will turn into one nice commit to the main branch.
I don’t want squashed commits. It makes git tools worse (
git bisect,git cherry-pick, etc.) and I work very hard to craft a meaningful set of commits for my work and I don’t want to throw all of that away.But yeah, I don’t actually give a shit what they are doing on their branches. I regularly rebase onto master anyway.
