this post was submitted on 21 May 2025
41 points (100.0% liked)
WordPress
728 readers
1 users here now
A place to talk about WordPress the open source content management system. Also a place to ask for help with WordPress. Don't be rude, don't spam.
I check this once a week, so if you don't hear from me hit me up on Mastodon ([email protected])
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
We do have it on git, after long insistence on my part, but it's just a pain in the arse having to undo all of what he'll merge into main.
Get really excited about vibe coding and tell your boss it works better if you make an AI specific branch. Toss main branch protections in and you’ve basically given your little brother an unplugged controller to play with.
Genius 😂
This guy 🫡
Just don't let him mess with main at all...
Time to change to rebase only workflow. Easy reverts.
Oh, what the heck. We've always worked rebase-only, so it never occurred to me that with merges you can't just check out a past commit and have it actually be the state of the project that it was back then...? Is that right?
If so, why does anyone work with merges?
So you can get the exact state at any commit, that still works. The problem really is that the merge commit itself contains the changes necessary to resolve conflicts between branches being merged, and may also include reviewer changes or who knows what.
Some people like it because it is more like the "real" history of your project; however it can make reversion of atomic changes much more difficult because the "atoms" in the final project may belong to more than one commit. It also makes the history pretty hard to follow on my opinion. I think it also opens the door to craziness like people having self-merges in their own branches because they didn't keep server code and local code for their branch in sync, though CI/CD might catch that... I never had an automated review process at work.
There is probably a time and a place, like when you're literally combining projects, but for fixes and features I don't agree.
I learned git working with students, and I need shit to be easy to follow and easy to revert. Hence atomic commits only and linear history :).