I remember learning about how to use this back in the day and what a game changer it was for my workflow.
Today I like to do all of the commits as I’m working. Maybe dozens or more as I chug along, marking off waypoints rather than logging actual changes. When I’m done a quick interactive rebase cleans up the history to meaningful commits quite nicely.
The fun part is that I will work with people sometimes who both swear that “rewriting history” is evil and should never be done, but also tell me how useful my commit logs are and want to know how I take such good notes as I go.
At my company we just use a squash policy in gitlab. Every merge request becomes a single commit to the main branch. Super easy to read the commit log because all commits are descriptive instead of a bunch of “fix MR comments” or “fix pipeline errors”.
Another advice: git reset [commit-id] followed with a git commit -a is a quick way to squash all your commits.
Yes - “Rewriting history” is a Bad Thing - but o argue that’s only on ‘main’ (or other shared branches). You should (IMHO) absolutely rewrite your local history pre-push for exactly the reasons you state.
If you rewrite main’s history and force your changes everybody else is gonna have conflicts. Also - history is important for certain debugging and investigation. Don’t be that guy.
Before you push though… rebasing your work to be easily digestible and have a single(ish) focus per commit is so helpful.
review is easier since concerns aren’t mixed
If a commit needs to be reverted it limits the collateral damage
history is easier to follow because the commits tell a story
I use a stacked commit tool to help automate rebasing on upstream commits, but you can do it all with git pretty easily.
The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.
This is really the only sane way to do it. I have run into some wonkyness with the commit history of the target branch commits not resembling git log, but that’s usually for commits outside of what I’m trying to merge.
Edit: squashing commits down this way also helps reduce problems with replaying commit history on the actual rebase. In most cases you don’t need all your “microcommits” in the history, and fewer commits just takes less time to reconcile.
I had my PC built for me while all i had to do was specify parts, tried to get fans with no light just to avoid this, got the almost exact model but with lights.
Now if i use my PC at night my room glows pink (not for any particular reason besides it being the most dominant in my rainbow led fans)
Why am I not surprised that someone who unironically quotes Ben Shapiro thinks of Elon “My Dad Owns An Emerald Mine” Musk as a shining example of capitalist meritocracy
the people who do that probably don’t even know that the ‘AI LE BAD’ is the same technology that is giving them precious views.
This fact is at best useless and at worst deliberately misleading.
The microcontroller inside my microwave oven that counts down seconds and shows me the time is a computer. It can execute instructions, do math, and emulate a universal Turing machine (or would be able to if it was connected to infinite memory). The Pleiades supercomputer at NASA is a computer. It, too, can execute instructions, do math, and emulate a universal Turing machine, albeit much more quickly. These two computers do such vastly different jobs and differ by so much in computational ability that referring to them using the same term is almost meaningless. Just because predicting what a user will click on and generating an image from a text prompt are both done using convolutional neural networks does not mean that the people who rally against the latter while relying on the former for an income stream are hypocrites. Good grief, you might as well accuse someone watching cat videos on their PC of warmongering because computers are also used for missile guidance.
He’s just an entrepreneur who really wants to play the Tony Stark role but doesn’t really know much more than the average tech hobbyist, so now he’s doing a bad-mediocre job at both things.
I use interactive rebases to clean up the history of messy branches so they can be reviewed commit by commit, with each commit representing one logical unit or type of change.
Mind you, getting those wrong is a quick way to making commits disappear into nothingness. Still useful if you’re careful. (Or you can just create a second temporary branch you can fall back onto of you need up your first once.)
If you’re using “trunk-based development” (everything is a PR branch or in main), this works great.
If you’re using GitFlow, it can make PRs between the major prod/dev/staging branches super messy. It would be nice if GitHub would let you define which merge strategies are allowed per-branch, but that’s not a thing (AFAIK). So you’re probably better off not squashing in this situation.
The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.
Only before you collaborate with anyone else. After that, don’t ever use rebase, or they’ll get an error, and will have to overwrite their local history with the one you’ve rewritten.
You could probably also try peeling off the outer plastic of the device so you can access the USB port and plug in an external keyboard, but the person holding it might notice
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.