| ▲ | grim_io 3 hours ago |
| Most of the colleagues I've worked with only use "git add ." without checking first. Keys, npm directories and huge binaries are fixed by deleting them later on. The horror. |
|
| ▲ | kryptiskt 3 hours ago | parent | next [-] |
| The problem is that those developers are also going to forget to update the ignore-by-default .gitignore to allow files, so there will be missing files. And they won't see any problems, because it works on their machine. |
| |
| ▲ | Tuna-Fish 2 hours ago | parent | next [-] | | That's fixed by having the CI server compile the code and run tests, and having it fail the merge and publicly shame the offender in slack when that happens. It's often said that you can't fix behavioral problems with technology, but I've found that tooling that strictly enforces rules is really useful. | |
| ▲ | yurishimo 3 hours ago | parent | prev | next [-] | | In my opinion this will pretty quickly solve itself though. Accidentally committing keys to the repo potentially ruins your entire week. With a default disallow all list, you might have one bad deploy oopsie and then commit the files. | | |
| ▲ | ozim 3 hours ago | parent [-] | | One problem I see all the time is that people are not using proper tools. Yeah command line is cool and all but I do believe most of the developers should be using UI tooling where staging area is showing nice diffs. Built in GIT handling in IDE usually is better than command line but also usually worse than dedicated tool like GitExtensions or SourceTree which are free and are super convenient for staging. People don't know they don't have to stage whole files but they can stage hunks, well in command line it is too much hassle for me but in GUI tools it is no brainer. I recommend looking here:
https://git-scm.com/tools/guis (it might be that you will be waaay cooler using GUI tool because you will be able to fix things others can't ... saying from my experience) | | |
| |
| ▲ | godelski 3 hours ago | parent | prev [-] | | It's at least easy to fix. Not pushing a file has a much easier fix than pushing an API key. The damage is also very different. Sure, both have failure modes but the effect of the failure is different and acting like they're the same isn't helpful to finding solutions |
|
|
| ▲ | tyre 29 minutes ago | parent | prev | next [-] |
| > Keys, npm directories and huge binaries are fixed by deleting them later on. The horror. Keys that are deleted are not gone from the git history. They’re still in the repo. Same with giant blobs and binaries. |
| |
|
| ▲ | agentdev001 an hour ago | parent | prev | next [-] |
| Secrets shouldn't be plain text in project directory >:[ |
|
| ▲ | embedding-shape 3 hours ago | parent | prev [-] |
| > Most of the colleagues I've worked with only use "git add ." without checking first. I mean I do too, then git status to check what went it, then unstage files that aren't supposed to be there, rewrite .gitignore to exclude them (usually), and finally commit. Tends to be faster than manually adding each file/path. Alternatively, I start out with `git add -p` (interactive) and go through that workflow. |
