First of all i want to thank your great work in explaining github.
I ve one doubt: in module 0, being selective you say many people use git add . and you don recommend to use it, as commits have to be in logic units.
But for example if you use a IDE as Eclipse, for programming in Java, and you want to add to create a new object… then many files get involved, and probably you wont know all the files being modified by Eclipse itself…or if you want to refactor the name of a class used in a whole project.
I think in these case its useful to use git add . and the problem is more in the commit instruction than in the git add itself…Students/users have to make a commit using logical units as said before…
Id glad to hear your opinion and if something that i havent understand…
Thanks and sorry for my bad english…
Hi Eduardo, here are my views.
When they say that
git add . is not good, it’s for two reasons:
- It combines all changes into a single commit, even if the changes were made for different purposes.
- It causes files that are should not be included in git to be committed.
When we create a commit, we deliberately add all of the changes related to a new feature etc, into a commit and give it a meaningful messages.
The description that you gave suggests that you may still have some misunderstandings of source control that hopefully we can help with: “to create a new object… then many files get involved, and probably you wont know all the files being modified by Eclipse”
A developer shouldn’t commit files to source control that we don’t understand the purpose of. I think what you’re saying is that when you create a new class, your IDE may create or alter additional files, e.g.:
- class files that are generated when you compile the code
- IDE settings files that describe the layout of eclipse as you open and close windows.
- cached dependencies that are downloaded for libraries that you added for your new class.
In my opinion, but I think this is generally accepted, none of these things should be committed to source control. If you edit or crease a java file then this, and this alone should be committed to git, and not the other “stuff” that the IDE generates. Part of the issues with committing these files are that the clog up git with files that will be re-generated anyway based on the source, or they are settings files that are specific to you and your IDE configuration that other people don’t want.
Often the answer to all of the above it to use
.gitignore to exclude all of the compiled or configuration files from appearing in a
git status. If this is done correctly then usually
git add . will indeed only add the files that you personally edited.
Hope this helps.
Thanks for your help.
I understand your point of view and i agree almost totally.
I was thinking when many files are touched/modified ex: when you refactor and change name to a variable or class in java. Eclipse or IDE should change the name in all appearance of the refactor object. Also to develop Android apps that it changes many files when you add a button or input text field
So i agree that comits has to be logical units in order not to mix things, but im totally newbie in these i think the important point is how often do you make adds and commits. If you make git add . once a week and then commit my work week20 then i asume is a mess. If you make git add . every feature almost or every change and then commit then the things dont get mixed.
Ex: i create a new menú in Android app, so many files get involved, i sabe the Project, make git add . and then commit “Added menú to App” — this way you dont mix things…. I was thinking about using commit very often almost every new step, feature i program. If you have lots of commits then you can roll back easily.
Thanks again for your help
Correo para Windows 10
Yes, you should commit often and this will help to keep the commits focussed on a specific purpose.
I understand now that the IDE is creating or changing files for you as you use it to update your application. However, I still believe that it is the developer’s duty to understand what each of the files is for and what the change does, even if the IDE made the change. Then we can choose which files need to be submitted to source control and which should not be.