If they did not commit all the important files and your CI system didn't catch that, that's definitely the fault of your CI system, not global gitignore.

Because there isn't a CI?

Shocking I know /s.

But not everyone on here is part of a 20 man SV tech startup making the next social media for beagles and deploying 50 times a day...

You don’t have to be at a tech startup to have things like CI and/or code review platforms.

Agreed. If the code is in GitHub, it's incredibly easy to create a simple github actions workflow that could run the app.

so glad i don't work with you.

Why? They're right imo

fishywang's attitude

What attitude lmao. They’re very matter-of-fact in expressing an objective opinion from what I can see.

what perceptive skills lmao! i couldn't stand talking to you for 2 minutes.

lmao!

I don't understand, you'd rather work without a CI pipeline?

i'd rather not work with fishywang

You might have learned the wrong lesson.

A broken code should not be able to make it to production, there should be several steps to prevent that, including: Peer review, CI, QA, a staging environment, manual testing, etc.

Always assume that developers can screw up in trivial ways, and build your delivery system such that trivial screw ups will be caught early, rather then dictate how your devs setup their work stations.

Also don’t code review the code it self, review the diff.

Yeah exactly, if I `require important.rb` in this file, and `important.rb` wasn't committed how did that project even build and get deployed. Any sane build system will instantly fail for this situations. Looks like an issue with dev ops/engineering culture rather than .gitignore

>Also don’t code review the code it self, review the diff.

A significant percentage of the most critical problems I detect during reviews is in the parts that have not been changed, invisible in the diff. A good diff is necessary, but not sufficient.

Telling developers to not use the global .gitignore seems to be the wrong response. For example, I use VS Code, its extensions, and various other development tools that create local files that should not be in repositories. Those files and directories do not belong in a repository's .gitignore file, unless it's a personal project. They most often belong in a global .gitignore unless a team uses a common set of tools. Having a single developer's custom tools be handled by a repository's .gitignore seems to be the wrong approach.

.git/info/exclude seems like the right place for this.

That's only per repository, isn't it? It won't really be convenient when you're working across several repositories or languages.

how did that project ever build on ci :)

hint: there was no CI

I heavily advise AGAINST not using CI. If properly applied it solves .gitignore mistakes and many more, made by those infamous junior devs. On second thought, not just juniors. Oh well.

but it worked on my machine

Ship your machine as CI, problem solved /s

Probably the dev made the code review before leaving