There is a spider outside my window at work that I've named Vanessa. She is a web developer. And every time I squash a bug, I feed it to her.

If your IDE found

10 errors

and 47 warns

would you correct them

or let them slip.

YO ...

His palms are sweaty

Knees weak, arms are heavy

The tests are failing already

Code spaghetti.

He's nervous,

But at his laptop he looks calm and ready
To squash bugs

But he keeps on forgetting

What he wrote down, the whole team goes so loud

He opens his file, but the code won't come out

He's chokin', how, everybody's jokin' now

The deadline run out, times up, over, blaow!

Snap back to reality, oh there goes file integrity

Oh, there goes documentation, he choked

He's so mad, but he won't give up that easy? No

He won't have it, he knows his whole header's code

It don't matter, he's dope, he knows that, but he's broke

He's so stacked that he knows, when he goes back to his mobile home, that's when its

Back to the office again yo, this whole rhapsody

He better go capture this moment and hope it don't pass him

Note: All credits to the original owners of these phrases.

Every time you squash a bug before someone else even sees it...

Lead: "There's a bug, you fix"
Me: "The PR for that has been waiting for your review since yesterday..."

What's your favorite shell alias that you made for yourself?

I use this one all the time:

squash () {
git rebase -i HEAD~${1}
}

Runner up though is `git-fuckit` which resets everything to origin/master.

Chasing a bug down in CSS, fuckity fuck fuck.

I will find you, and I will squash you.

I just had a dream about how to squash a bug I was encountering in my app. I immediately woke up, fixed the bug, and cleaned up my code. I thought this only happened in movies.

My progression of learning git rebase:

Year 1: WTF just happened?! Where is my code?! *deletes and re-clones repo*

Year 2: Ok if I do it suuuper carefully I can get the other dev's one-line change into my branch...shit...shit...wait...fuck...oh lol it worked.

Year 3: Oh yeah let me organize my commits real quick. *drop pick pick squash reword pick fixup drop pick* *git push -f* 😎

I'd like to apologise for devRantron updates being a bit slow, both me and tahnik are still in school so we don't have much time right now.

We'll be working on implementing themes during the Christmas break and we'll also try to squash some bugs.

Hope you understand 🙂
PS. Thanks for the awesome support and feedback were getting ♥️

"Me getting ready to squash the bug" vs
"Me after fixing the bug caused by my own stupidity"

Partner of ours claimed they are going to update their api. No breakage. My hopes were low and they did not disappoint.

Soon after the new version of their api went live, of course, loads of breakage. And the email contact with them is really fun.

Me: "Hello, since your update we get the issue A. Here's the complete communication."

Them: "We did not change the existing behavior. You are doing X wrong. Repeat that one call during the step and you should be fine."

Me: "Thank you, if I repeat the call, it does indeed work, albeit slower, since we are now repeating calls. Furthermore, our application was consuming your api for years and we did not change anything. So why is that step necessary now? Only after your update do our logs show errors from your API. And by the way, we now also have a issue with B. Why is that?"

Them: "Oh that's because your query the endpoint with "Fnord", try "Baz".

Me: "Yes, I do know that we query it with "Fnord" as that is what a previous endpoint of yours is responding to us. Why are we getting "Fnord"? What request do I have to make to get a "Baz" back?"

It feels like a game of wackamole. Squash one issue, ten more will pop up. I am one step away from becoming active-aggressive.

How much exercise do you guys tend to do? There's definitely a stereotype that developers aren't particularly sporty, but I break that mould (gym, squash, rock climbing, skiing, etc)

Any other sporty developers out there?

Starting the day with 4 bugs to squash...end the day with 3 done and 7 to go... Wait.. What??

Programmer’s life cycle:
- Nothing can stop me today
- A bug huh? let's squash
- I can’t fix this
- Confidence crisis
- Questions career
- Questions life
- Oh it was a typo
- Nothing can stop me today

So recently my open source project took off and got trending on GitHub (680 starts and 225 forks). This was the first time a project of mine really gained some traction and invested more of my time and weekends to maintain this project - I wrote comprehensive docs, contributing guidelines and reviewed PRs and made sure I commented on every single one of them. Sure, it isn't easy to review 50 PRs a day after coming home from work but the excitement of seeing this project becoming trending fueled me.

First 2 weeks it was good. I would come home from work and have dinner and sit down to maintain the project. Whenever contributors would be stuck, I would help them and write comments on each PR.

But the problem started since last week. People just really want to see their contribution activity graph get populated and hence they would make stupid PRs and literally no one followed contributing guidelines - I mentioned in that that the code should adhere to Pep8 styling but no one gave a shit. Each day I would spend reviewing PR with crappy formatted code and no sign of Pep8, and even some will just file PR and add a fucking docstring to every function or add paragraph of comments. Also, the PR quality was bad with unsquashed commits amounting to 10 or 20 or even sometimes 50.

I wrote the contributing guidelines doc and in that I mentioned every source that contributors could find helpful like how to squash commits, how to file a PR and Pep8 and not to write useless comments. Seriously people, grow up!

Today I learned why it’s so important to have life outside engineering (better put, I remembered this).

For the last couple of weeks, we’ve been working hard to catch some deadlines, contributing to a large oss project. Getting up at 4am, working with the team in my timezone, having some time with family then working with people with 6-9 hour difference was extremelly challenging and I was so tired I literaly was a fucking pain to bear with.

Today, on Saturday, my wife started cleaning the bathroom sink drain. You know, started... “won’t fix” was not an option. First, the dirt and the smell, mmmmmm, you just have to love it. And then the thing collapses (yes, I was optimistic, trying to clean it just partly - I learned not to fix if it aint’t broken, I wonder where).

It’s of course built of trivial parts, but the water just finds its way. Needless to say, I am afraid of it :). In the end, it got resolved. Just as any bug we squash - with some anger and plenty of dirty words.

During the whole thing, I thought to myself, that all that stress at work is quite bearable; it put everything back into a perspective. Great feeling!

So this just happened,

Me and my co-worker (we are junior developers) were working on the same bug, it was a post call throwing a server exception.

We had asked for help to debug this issue from a senior developer the day before, he was quite busy with his own tasks.

He is one those kinds who would keep working even if the entire bay is wasting their time, always keeping to himself, needless to say I haven't seen him smile.

Back to my story, he couldn't spare time yesterday so we tried to squash the bug ourselves thinking he might have forgotten we had called him.He then comes out of nowhere, he firsr checks the button bindings, params sent and the call being made.

He then went through the backend code strategically placing the break points, clicks and debugs a few times and then opens the console. BAM!!!!

" D' hell yo !!" Shows up in the console, not just once but multiple times. Turns out I forgot the logger I had placed in the catch block.

He turns to me in super slo-mo looks me in the eye and whispers "what the hell yo!" and kept quite for some time, meanwhile the sense of cringe was slowly creeping on me. That was when he let out a loud blurt and the entire cabin turned to us. Needless to say it was awkward.

His smile was creepy though :/

When a bug was much easier to squash than expected! Excellent!

Why squash commits when you can just --amend the commit and git push -f

#SecretsOfADumpsterFireDeveloper

My former housemates had a cat, they moved out and took said cat. Cat had fleas which I wasn't informed of.

Cleaning out the now vacant room with a can of flea spray in hand I utter:

"Now, my uninvited friends, sooner or later, even if I have to do it individually, by hand at times, I will find you all and I will squash you for I am a software developer and I deal with bugs all the time."

>Sitting at desk pondering over what is wrong with code.

:Top

BRAIN : "maybe we will think better with /another/ cup of cofee?"

Repeat until

BRAIN : "damn now im too jittery to think about code. Maybe if I relax woth some music/meme hunting ill be able to focus"

Repeat until

BRAIN : "Damnit i spent 2 hours on 9gag and not coding. Gotta get back to this bug squashing but im now so tired. Maybe some cofee will help me think"

Goto Top

Merge VS Rebase:
- Did you pick a side?
- Practical tips? Like dealing with merge conflicts
- Have you ever regretted using either?

My answer
* My team squash-merges all branches to master so we don't really care what the branch history looks like. Master history should be pretty - but a branch history can be ugly and filled with a dozen commits.
* Practical tip 1: use `git config rerere.enabled true`. rerere stands for "reuse recorded resolution" and this means if you rebase often you don't have to resolve the same merge conflict twice.
* Practical tip 2: use `git commit --fixup oldcommithash` and then rebase with `--autosquash`
* I like using Rebase. But I have regretted the amount of time I've spent on trying to rebase old branches with many commits only to give up and to `git rebase --abort` since I realised I couldn't handle trying to reapply all the commits chronogically as the changes in the 1st commit were no longer relevant.

Bugfixing is like whack-a-mole... For every one you squash, 3 more pop up.

Proudest bug squash? Probably the time I fixed a few bugs by accident when I was just trying to clean up an ex-coworker's messy code.

So I used to work with a guy who was not a very good programmer. It's hard to explain exactly why other than to say that he never really grew out of the college mindset. He never really learned the importance of critical thinking and problem-solving. He did everything "by the book" to a point where if he ran into an issue that had no textbook solution, he would spin his wheels for weeks while constantly lying to us about his progress until one of us would finally notice and take the problem off his plate. His code was technically functional, but still very bad.

Quick Background: Our team is responsible for deploying and maintaining cloud resources in AWS and Azure. We do this with Terraform, a domain-specific language that lets us define all our infrastructure as code and automate everything.

After he left, I took on the work to modify some of the Terraform code he'd written. In the process, I discovered what I like to call "The Übervariable", a map of at least 80 items, many of them completely unrelated to each other, which were all referenced exactly once in his code and never modified. Basically it was a dynamic collection variable holding 80+ constants. Some of these constants were only used in mathematical expressions with multiple other constants from the same data structure, resulting in a new value that would also be a constant. Some of the constants were identical values that could never possibly differ, but were still stored as separate values in the map.

After I made the modification I was supposed to make, I decided I was so bothered by his shitty code that I would spend some extra time fixing and optimizing it. The end result: one week of work, 800 lines of code deleted, 30 lines added, and a massive increase in efficiency. I deleted the Übervariable and hardcoded most of the values it contained since there was no possible reason for any of them to change in the future. In the process, I accidentally fixed three bugs that had been printing ominous-sounding warnings to the console whenever the code was run.

I have a lot of stories about this guy. I should post some more of them eventually.

A big project in my company. Had some annoying race condition that caused data to get deleted when two processes finished in the wrong order they hit the dB and override each other’s work.

Long story short. Fixed the bug and in the process the codebase shrunk by 60%. I didn’t have to delete the rest of the code, but the bug was due to a function in the legacy section of the code, and found out that it was the only function used in that section.

So I deleted it. Rewrote the function so it upserts. And bam. Smaller, cleaner code :)

I would be have to say waking up to fix bugs really works better than coffee

Proudest bug squash experience?

Fixed a N+1 pattern bug on our web site. Wasn't a deeply technical problem, but I was proud to shove the fix up the arse of the developer who blamed me (and even got a VP involved) for the web site crashes (the N+1 involved his code calling a service I wrote) and none of the half-dozen other devs found it.
I really wanted to make a t-shirt with his initial 'blame' email outlining all the 'technical problems' with my service, and the fix was literally moving the service call outside 5 (yes 5) level deep for..each loops.

I don't know who you are. I don't know what you want. If you are looking for ransom, I can tell you I don't have money. But what I do have are a very particular set of skills, skills I have acquired over a very long career. Skills that make me a nightmare for bugs like you. If you let my program go now, that'll be the end of it. I will not look for you, I will not pursue you. But if you don't, I will look for you, I will find you, and I will debug you.

Thanks GitLab.

After I get notifications about the final replies to my 6 month quest of updating someones GitLab README, I didn't expect MY fork to have been modified ( and thanks to that, made ugly / they removed all spacing, vertical & horizontal )

Where the fuck even was the option that GitHub offers where it prevents people from just doing whatever to your shit in a PR?

Why the fuck isn't this a permanent setting for either ( lab & hub ) so I don't have to manually turn it off every single time.

I didn't even think about that option up until now, since the maintainers didn't touch anything and everything seemed fine, but now that it was about to be merged, they suddendly got the bright idea of squashing everything into one commit and that on my fork itself, .. really helpful.

Just an update : never fucking install windows 7 on a new desktop without first reading , fucking piece of shit won’t detect my SSD , tried different solution over the Internet to no success, after 3 hours of nerve wrecking debugging I read a post on the Internet that “some”(not sure which) versions of windows just don’t detect an SSD,
Finally done by installing windows 10,
But nooooooo will windows let me die in peace, noooooooo
Every fucking time I restart my PC “ windows is installing updates
I mean fuck you , how fucking many bugs do you squash in a day.

Probably some engineer at Microsoft will be “ oops o dropped a donut on my keyboard, let just press ctrl + z” to undo changes and upload , lol “

I made a huge mistake

I got "in the zone", I was coding so nice and fast and everything was working, so I didn't want to commit every single minute and then have to go back, cherrypick commits squash them revert them etc.

So I didn't commit anything at all... Now if I were to commit the commit would modify 2 files, create 26 new files and delete 2 files.

The changes include moving from JS to TS, implementing a desearialization scheme, implementing a server class and wrapper client classes, with common type interfaces for different requests...

So now I need to save my changes somewhere, go back to the last commit and slowly incorporate the changes.

I'm dumb

Just had a bug reported that only happens in Chrome. Works in IE and Safari. This is going to be an impossible bug to squash.

I love git stash.

It's helps a lot for doing refactors to me. I guess it's not the most complex workflow, but it wasn't obvious to me when I started with git. Let me explain.

Refactors. As you start writing the first lines of a refactor, you start to notice something: you're changing too many things, your next commit is going to be huge.

That tends to be the very nature of refactors, they usually affect different parts of code.

So, there you are, with a shitload changes, and you figure "hey, I have a better idea, let me first do a smaller cohesive commit (let's call it subcommit) that changes a smaller specific thing, and then I'll continue with the upper parts of the refactor".

Good idea, but you have a shitload of changes nearly touching every file in your working copy, what do you do with these changes? You git stash them.

Let's say you stash and try to do that smaller "subcommit". What sometimes happens to me at this point is that I notice that I could do an even smaller change inside this current "subcommit". So I do the same thing, I git stash and I work on that even smaller thing.

At some point I end up `git stash pop`ing up all these levels. And it it shows that git stash is powerful for this.

* You never lose a single bit of work you did.
* Every commit is clean.
* After every commit you can run tests (automated or manual) to see shit is still working.
* If you don't like some changes that you had git stashed, you can just erase them with git reset --hard.
* If a change overlaps between a stash you're applying and the last "subcommit", then
if they differ, git shows conflicts on the files,
if they are identical, nothing happens.

with this workflow things just flow and you don't need to wipe out all your changes when doing simpler things,
and you don't need to go around creating new branches with temp commits (which results in bloated temp commits and the work of switching branches).

After you finish the refactor, you can decide to squash things with git rebase.

(Note: I don't use git stash pop, because it annoys the fuck out of me when I pop and you I get conflicts, I rather apply and drop)

Have been pissed at the guy who wrote the js on the project im working on (its just so messy!). Same project has python scripts I need to look at to squash a bug, and this. code. is. so. clean. They should have let this guy write everything in python. Im ashamed I ever hated on him.

Issue about adding squash feature for git pull request merges on Bitbucket has been open for years...

Bonus level: you have to use Bitbucket

let me preface with the fact that I'm now known at my new job for being the resident cli hipster. I can't lay any claims to knowing if it's "better" but I like it, I don't care if you do or don't, it just works for me and my flow

so at my job, we generally squash all our commits into one commit and delete the source branch upon merging; i accidentally committed all my work to an old, already merged branch, so my boss tells me it would be more of a PITA with the weird references we would encounter by merging the branch again, rather than just cherry pick the commits into a new branch, which i'm like "eh, fine.".

HIM: "You want to share your screen so we can resolve this?"
ME: "k"
HIM: "Oh, you won't be able to do this in a terminal, you are going to have to load up a GUI of some sort"
ME: "lawlz, no you don't"
HIM: "i highly doubt you will be able to accomplish that, but if you wanna make an ass of yourself, i'll humor you"
ME: "yeah, watch this"

> git log > log.txt
> git checkout <new branch>
> git cherry-pick <copy-paste-full-commit-hash-here>
> git push

ME: "done"
HIM: "what? there's no way you did it that easily, where are all your other commits???"
ME: "i usually try to amend my commits since we squash them anyhow. it really helps in situations like this"
HIM: "well, you go girl"

roll that up in your fancy degree and smoke it, why don't ya?

git rebase > git merge

I'm honestly tired of colleagues completely fucking up the git history along with creating conflicts for no reason at all.
How do you even manage to "recommit" changes when merging?

I can't even squash properly because there are 5 merge commits on the feature branch. Fuck off

We've all been there before mastering git commit --amend, rebase, and squash

The last one and only one I joined was online and called “flex bug squash”.
It was about ~8-9 years ago.

I won Flex Builder desktop software license and I was using it after so I think it was cool.

Fun, creative times it was.

That was also first and last significant thing I won and then Steve killed flash on mobile and as a result killed flash.

Thanks Steve if you’re reading this.

Today I played with GitHub Actions. Since I couldn't test anything without making a commit and pushing it to GitHub to trigger the workflow, my commit history now chronicles my slow descent into madness. Thank God it's a private repo. I'm gonna squash it if I ever make it public.

This gem is from hour two of my four-hour struggle:

Is it me or do programmers just skip dinner unknowingly because you just wanna squash that one feature before you head home? But you realise that it's already 12am?

git rebase is like fish.

Hours after the kill: hmm, tasty.
A day after the kill: not too bad.
A few days: time to toss this in the trash
More than a week: dig a hole and bury this thing before it stinks up the neighborhood.

That being said, I'd rather eat a plate of Hákarl than deal with rebasing a diverance that is over a month old. I simply don't use rebase. It's just too stinky. I just merge very often and keep things in sync.

If you need the effect of a rebase without the crazy hassle:
git checkout master
git checkout -b rebase_branch
git merge --squash dev_branch

Turns out that stuff you commit and remove in later commits stays in git history and is searchable.
That, kids, is why you either squash your commits or just don't put swears in your debug code.
Especially if you have literally dozens of colleagues on the same codebase.
And you work in a large organisation where this sort of thing is frowned upon.

The crime was months ago, I wonder what the statute of limitations is on that.

And yes, in the years-long history of the codebase it's JUST me that's used any of the big three.

OMG Squash your damn commits!

is it necessary to have cherry picking a part of git branching/release process?

we have 3 branches : develop, release and master.

currently every dev works on feature as follows : they make a branch out of develop, write code, raise pr against develop, get it reviewed and merge back to develop. later the release feature list is generated, and we cherry pick all the release related commits to release branch, and make a prod build out of release branch. finally, the code is moved to master and rags are generated accordingly.

so the major issue with this process is feature blocking. as of now, i have identified 4 scenarios where a feature should not be released :

1. parallel team blocker : say i created a feature x for android that is supposed to go in release 1.2.1 . i got it merged to develop and it will be cherry picked to release on relase day. but on release day it is observed that feature x was not completed by the ios dev and therefore we cannot ship it for android alone.

2. backend blocker : same as above scenario, but instead of ios, this time its the backend which hasn't beem created for the feature x

3. qa blocker : when we create a feature and merge it to develop, we keep on giving builds from develop branch adter every few days. however it could be possible that qa are not able to test it all and on release day, will declare thaf these features cannot be tested and should not be moved to release

4. pm blocker: basically a pm will add all the tickets for sprint in the jira board. but which tickets should be released are decided at the very late days of sprint. so a lot of tasks get merged to develop which are not supposed to go.

so there's the problem. cherry picking is being a major part of release process and i am not liking it. we do squash and merges, so cherry picking is relatively easy, but it still feels a lot riskier.

for 1 and 2 , we sometimes do mute releases : put code in release but comment out all the activation code blocks . but if something is not qa tested or rejected by pm, we can't do a mute release.

what do you folks suggest?

Today, rebase finally made sense to me and I was able to squash a branch to remove a whole lot of unnecessary commits.

It only took 2 years... Guess all three times I used git in command line and all the Linux terminal/acting finally made a synergy.

Given I had to use force push that means it's like overwriting an existing repo with a different one?

When you have a brain fart and forget the difference between fix-up and squash in Git rebasing. Why yes I wanted to stay an hour late at work redoing the changes I just lost!

When you're getting roasted and given tasks of fixing and changing some code you didn't write trying to get a PR in, and the person you paired with who wrote it has moved on to other work.

Moreover you'll be stuck taking the blame down the road if they don't fire you, as the policy is to rebase squash merged in PR's so it will all unfortunately be under your name.

Question about git. I worked on dev branch and made 10 commits.

Then I squash merged 10 commits from develop to master and made a release build.

Now problem is if I make a pull request from develop to master bitbucket will still show that master is behind (because develop has fixes in 10 commits while master has all of them squashed in 1 commit).

Now my question is whats the best way to make sure master and develop are synced (basically that master would have everything what develop has) ?

should I just merge master into develop back after the release?

Me: You didn't squash that PR into develop....
Them: There was no option to squash...

AAAAAAAAAAAAAAAAAAAAAA 🙂

Thank god for the squash and merge feature on github... 1/3

"The Perils and Triumphs of Debugging: A Developer's Odyssey"

You know you're in for an adventurous coding session when you decide to dive headfirst into debugging. It's like setting sail on the tumultuous seas of code, not quite sure if you'll end up on the shores of success or stranded on the island of endless errors.

As a developer, I often find myself in this perilous predicament, armed with my trusty text editor and a cup of coffee, ready to conquer the bugs lurking in the shadows. The first line of code looks innocent enough, but little did I know that it was the calm before the storm.

The journey begins with that one cryptic error message that might as well be written in an ancient, forgotten language. It's a puzzle, a riddle, and a test of patience all rolled into one. You read it, re-read it, and then call over your colleague, hoping they possess the magical incantation to decipher it. Alas, they're just as clueless.

With each debugging attempt, you explore uncharted territories of your codebase, and every line feels like a step into the abyss. You question your life choices and wonder why you didn't become a chef instead. But then, as you unravel one issue, two more pop up like hydra heads. The sense of despair is palpable.

But, my fellow developers, there's a silver lining in this chaotic journey. The moment when you finally squash that bug is an unparalleled triumph. It's the victory music after a challenging boss fight, the "Eureka!" moment that echoes through the office, and the affirmation that, yes, you can tame this unruly beast we call code.

So, the next time you find yourself knee-deep in debugging hell, remember that you're not alone. We've all been there, and we've all emerged stronger, wiser, and maybe just a little crazier. Debugging is our odyssey, and every error is a dragon to be slain. Embrace the chaos, and may your code be ever bug-free!

One of the worst practices in programming is misusing exceptions to send messages.

This from the node manual for example:

> fsPromises.access(path[, mode])

> fsPromises.access('/etc/passwd', fs.constants.R_OK | fs.constants.W_OK)
> .then(() => console.log('can access'))
> .catch(() => console.error('cannot access'));

I keep seeing people doing this and it's exceptionally bad API design, excusing the pun.

This spec makes assumptions that not being able to access something is an error condition.

This is a mistaken assumption. It should return either true or false unless a genuine IO exception occurred.

It's using an exception to return a result. This is commonly seen with booleans and things that may or may not exist (using an exception instead of null or undefined).

If it returned a boolean then it would be up to me whether or not to throw an exception. They could also add a wrapper such as requireAccess for consistent error exceptions.

If I want to check that a file isn't accessible, for example for security then I need to wrap what would be a simple if statement with try catch all over the place. If I turn on my debugger and try to track any throw exception then they are false positives everywhere.

If I want to check ten files and only fail if none of them are accessible then again this function isn't suited.

I see this everywhere although it coming from a major library is a bit sad.

This may be because the underlying libraries are C which is a bit funky with error handling, there's at least a reason to sometimes squash errors and results together (IE, optimisation). I suspect the exception is being used because under the hood error codes are also used and it's trying to use throwing an exception to give the different codes but doesn't exist and bad permissions might not be an error condition or one requiring an exception.

Yet this is still the bane of my existence. Bad error handling everywhere including the other way around (things that should always be errors being warnings), in legacy code it's horrendous.

What's the best merge strategy for PRs?

There's like a default then squash, ff-only.

A: oh hey my commit is not in the master branch...
A: *seeing bunch of commit deleted activity in bitbucket by B
A: Lol B deleted commits in master branch
B: Wait, what?! I know I have rebased my branch.. but never have I rebased anything in the master branch.. how can this be *intense breathing
B: Are you sure you have pushed yours to master?
A: Sure I've rebased, squashed, and rbt landed my work to master, here look my local master has my commit
CTO: wait what? Is this related to this bug we have in production just now? Please don't panic, let us resolve it

Turns out rbt land just squash your commit to your local master branch and they thus A have not pushed it to the remote. And the bunch of commit deleted activity were bitbucket not informing from which branch the activity was happening. Almost gave us heart attack.

And I thought I knew a lot about practical git... But today I learned about fixup commits and autosquash. Awesome!

Odd question to a dev community who are naturally socially awkward that talks to their ducks.

Even then, for those of us who do have a social life, we just chill when we need to. Anyone who "tries" to balance their life would find it very stressful. Just go with it. Do what you need to do at that scheduled time and when time is up, do the other thing that you promised yourself.

Others: "Easier said than done! You don't have to push releases and squash bugs in critical moments!"

Then that's a trigger to the question, "Do you even live, bro? There's more to life than just dev all day err'day."

Don't think too much.

On my free time I was looking for software where I could visualize the shape of the git graph to sort of reflect Git Flow. What I found was a bunch of git GUI's that list features that normal git already has:
- "undo local changes!"
- "squash commits!"
- "undo branch deletions!"
Da heck people actually pay for this?

GitHub defaults to only allow squash merging feature branches, and suggests that it is "safe" to delete the feature branch that contains all the detailed commit messages at the place where they belong. Losing history, plus creating unnecessary "conflicts" after continuing to work and adding fixes to the same feature branches later.

Been making minor refactors to code base. Ran into something that resembles and behaves like a brainfart. Accepts arguments, uses them to query DB then completely disregards result and builds own result yielding dubious output.
Dumb as I am, went to investigate the story behind it. Maybe some weird business rules involved.
Git gave commit. 100+ files changed. Nice one.
Went to original story and there it was, clearly stated, like a true moronic decision: "Squash all feature commits to a single commit". No specs, no description, no explanation... Nothing.
Well... FUCK YOU TO!

How to use git rebase when working with master and staging branch?

It might be a stupid question, but I really like the idea of creating a feature branch, work on it, if there are multiple commits squash them, rebase in top of master and then create a pull request from that branch to master.
It keeps the gut log pretty clean.

However, how would you do this, when not only working with a master branch but a staging/testing too?
Would you just rebase onto staging, merge to staging and when everything is fine, rebase onto master and merge again? Is there a netter way?

For a small team (<= 7 people) working on a self-managed Gitlab instance ('Starter' subscription), is it better if each user keeps a fork of the project they work on (working on other branch than master) or have everybody work on the same fork (still, different branches)?

Also, squash commits on branch merging, yes/no and why?

!rant
To embrace the TIFO (today I found out)
$git rebase -i <hash>^

You can reorder commits and squash.
I just used it, to amend a commit that was not HEAD with some changes I’ve done later.

When somebody doesn't squash their commits. And I have to look at commit with that line they deleted. So annoying!

How do you setup your ci/cd pipeline to work just like you want it, without having to create a quadrillion commits in your repository? Create a branch, make a quadrillion changes and squash them at the end? Is there a better way?

There is another place in hell for ppl who don't squash and merge :/

I was asked to make release branches which will change my gitflow. Am I understanding it correctly now? Fix me if I'm wrong

So I do my fixes in develop, once Im done I squash merge them into 1 commit. Then I make a release branch from develop, if everything is fine I release it. After release I merge back release branch to master and thats it?