It's not a good idea. You could add generated files, backups, and conf files with stuff you don't want added. It's better to use (small) trump cards like *.png or simply add file by file. You don't need to use git add every time you commit, git commit -am "message" will add to the commit everything that has been modified.
You could, but I typically have a command line + visualization set up and in most cases, I go with git add . and go through the verification step visually beforehand.
Well, I don't know. You might have some secret information in a .json or in a .yml file. You might exclude it by name in .gitignore, but then you would have to remember to do so. Routinely doing individual (or pattern inside a directory) is a better practice where you don't have to remember to add every possible file with non-public information to .gitignore.
Well, first of all, .gitignore is smarter than that. You can exclude using patterns and directories, the same as you can do for git add.
Second, in most cases, you shouldn't be putting secret information in the repository to begin with. Use a separate directory.
Third, think about the mind-memory load you're talking about here. Either you remember all the files with non-public information once and add it to a file (.gitignore), or you remember all the files period and discriminate which to add every single time (git add). You're having to remember what not to add ANYWAY. If you can use a mental shortcut like "Well, I never change .yaml", then you should be adding *.yaml to .gitignore. Work smarter, not harder.
In the end, it may depend on the project. I have never worked on a project where manually using git add instead of .gitignore was worth the tremendous expenditure of effort. There may be exceptions.
Ultimately, remember that Git offers both features because one size doesn't fit all.
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.
It's not a good idea. You could add generated files, backups, and conf files with stuff you don't want added. It's better to use (small) trump cards like *.png or simply add file by file. You don't need to use git add every time you commit, git commit -am "message" will add to the commit everything that has been modified.
You could, but I typically have a command line + visualization set up and in most cases, I go with
git add .
and go through the verification step visually beforehand.Well, I don't know. Your
.gitignore
really needs to be configured correctly, as a rule. I haven't added a wrong file in three years.I always use
git add -p
solved the problem for me tooWell, I don't know. You might have some secret information in a .json or in a .yml file. You might exclude it by name in .gitignore, but then you would have to remember to do so. Routinely doing individual (or pattern inside a directory) is a better practice where you don't have to remember to add every possible file with non-public information to .gitignore.
Well, first of all,
.gitignore
is smarter than that. You can exclude using patterns and directories, the same as you can do forgit add
.Second, in most cases, you shouldn't be putting secret information in the repository to begin with. Use a separate directory.
Third, think about the mind-memory load you're talking about here. Either you remember all the files with non-public information once and add it to a file (
.gitignore
), or you remember all the files period and discriminate which to add every single time (git add
). You're having to remember what not to add ANYWAY. If you can use a mental shortcut like "Well, I never change .yaml", then you should be adding*.yaml
to.gitignore
. Work smarter, not harder.In the end, it may depend on the project. I have never worked on a project where manually using
git add
instead of.gitignore
was worth the tremendous expenditure of effort. There may be exceptions.Ultimately, remember that Git offers both features because one size doesn't fit all.