Sorry for my English. I have a example about what @andreidascalu talking about.
My colleague left the company so maintaining his project now become mine. Whatever reason he doesn't ignore .DS_Store in the project's .gitignore. But, I have it ignored globally so I don't know it's not ignored in the project. A week later, a new intern join this project. he doesn't have global ignore like me so he accidentally commit and push .DS_Store to remote
In this example, it's just a .DS_Store what about .env or something that is really important like a key or token. I should notice and fix project's .gitignore on the first day if I don't have globally ignore.
notice the git incident and prevent it in the first place
secure the server
securing the server is only prevents it through to the server but the incident has already happened. the git incident is shouldn't happen in the
first place.
for pull request, we don't notice it until pull request is created. if we don't ignore it globally, it will be noticed faster. also have to clean up the commit, if sensitive files like .env already push to remote for creating pull request.
The git incident problem will not happen in 2 case
the project's .gitignore has been set correctly
everyone set their global gitignore correctly
For me set global gitignore is not scalable. When many people join the project later you need to tell them how to set their global gitignore properly or have some documentation for them. what if they miss config it, even they config it correctly it does not guarantee they will not miss config it later. It is hard to know when and what they miss config in later.
the project's .gitignore is more scalable when more people join the project later you don't need to have some documentation(it's still good to have one) or tell everyone that they need to set global gitignore.
I don't use global gitignore when I join a new project I can notice that the project's .gitignore is missing some config. This make me notice it fast and fixed the config to be correct for the other people. people who join the project later don't even need to set their global gitignore.
If everyone doesn't use global config when the project's .gitignore has something wrong everyone will notice it fast and fix it in no time.
If everyone uses global config it's hard to notice when .gitignore has missed config.
The project's .gitignore is prevent everyone to make a mistake.
The global gitignore is only prevent you to make a mistake but not the other and it makes you hard to know when the project's .gitignore is invalid.
Programming languages enthusiast. Author of Learn Type Driven Development: https://www.packtpub.com/application-development/learn-type-driven-development
Ignoring .DS_Store globally on my dev machine is a basic convenience measure. If this is a real worry in the team regarding security, then the team should be using a CI pipeline and running this (and other) security checks during pipeline builds. For example, check that .DS_Store must be mentioned in every project's .gitignore file, fail the build otherwise.
Yeah it sounded like a good idea but I've come to realize that what I don't like about it is its "do it once and then forget about it" nature. It's a bit, out of sight, out of mind, which mean that at some point you wouldn't even be aware anymore that you have it. The issue would be "solved" but you'd lose sight of it and not be aware of it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sorry for my English. I have a example about what @andreidascalu talking about.
My colleague left the company so maintaining his project now become mine. Whatever reason he doesn't ignore
.DS_Store
in the project's.gitignore
. But, I have it ignored globally so I don't know it's not ignored in the project. A week later, a new intern join this project. he doesn't have global ignore like me so he accidentally commit and push.DS_Store
to remoteIn this example, it's just a
.DS_Store
what about.env
or something that is really important like a key or token. I should notice and fix project's.gitignore
on the first day if I don't have globally ignore.I think it should be secure both way
securing the server is only prevents it through to the server but the incident has already happened. the git incident is shouldn't happen in the
first place.
for pull request, we don't notice it until pull request is created. if we don't ignore it globally, it will be noticed faster. also have to clean up the commit, if sensitive files like
.env
already push to remote for creating pull request.The git incident problem will not happen in 2 case
.gitignore
has been set correctlyFor me set global gitignore is not scalable. When many people join the project later you need to tell them how to set their global gitignore properly or have some documentation for them. what if they miss config it, even they config it correctly it does not guarantee they will not miss config it later. It is hard to know when and what they miss config in later.
the project's
.gitignore
is more scalable when more people join the project later you don't need to have some documentation(it's still good to have one) or tell everyone that they need to set global gitignore.I don't use global gitignore when I join a new project I can notice that the project's
.gitignore
is missing some config. This make me notice it fast and fixed the config to be correct for the other people. people who join the project later don't even need to set their global gitignore.If everyone doesn't use global config when the project's
.gitignore
has something wrong everyone will notice it fast and fix it in no time.If everyone uses global config it's hard to notice when
.gitignore
has missed config.The project's
.gitignore
is prevent everyone to make a mistake.The global gitignore is only prevent you to make a mistake but not the other and it makes you hard to know when the project's
.gitignore
is invalid.Ignoring
.DS_Store
globally on my dev machine is a basic convenience measure. If this is a real worry in the team regarding security, then the team should be using a CI pipeline and running this (and other) security checks during pipeline builds. For example, check that.DS_Store
must be mentioned in every project's.gitignore
file, fail the build otherwise.Yeah it sounded like a good idea but I've come to realize that what I don't like about it is its "do it once and then forget about it" nature. It's a bit, out of sight, out of mind, which mean that at some point you wouldn't even be aware anymore that you have it. The issue would be "solved" but you'd lose sight of it and not be aware of it.