4 ms·
Yes, the moment you construct a commit by 'git add' is the moment you review the changes you made. Very often you will find results or configuration files get a
by martopix 4y ago
Yes, the moment you construct a commit by 'git add' is the moment you review the changes you made. Very often you will find results or configuration files get added without you realising it; or you added a breakpoint() that you shouldn't commit, etc. Second, for meaningful commit messages, the commit should include changes that are related to each other.
In summary `git add --all` or `git add .` should be used only after a careful inspection of `git status` or `git diff` showed you indeed need all changes, and that they belong to the same commit message.
- formerly_proven 4y agoJust use git-gui
- throwawaylinux 4y agoLogical changes aren't necessarily partitioned by file. Very often I find they are not. I might make a feature or fix or cleanup that is say 10 related changes that each affect some subset of say half a dozen files, often even the same code multiple times. Adding individual files can help partition out some changes, but it's very rare for me, it's much more often I have to go back and manually shuffle sub-file changes around if I didn't get the splits right the first time.
- naavis 4y agoYou could use `git add -p` It lets you stage individual changes inside files instead of the whole file.
- throwawaylinux 4y agoRight, I can do those things and sometimes do. Similarly to per-file I generally don't need to because I try to write and commit a logical change at a time. I have no problem with people who do it some other way, it just seems odd to hear people proclaim a particular way to work with git is wrong, because it does not match how they work. Not sure if it's because they can't imagine any other way of working, or they just think all other ways are also wrong.