Why should someone use git add before git commit? OR why should someone use git add at all?

Question

I am not an expert in git and I understand that the whole idea behind version control is to be able to record the history of the files. If we can keep track of changes made to files in the working directory by making commits, then why should I perform git add to keep a record of the files when I can just git commit?

I went through this thread on SO and found this:

I use git add when I think a file is ready to be committed, even if I know I won't make the commit until some time later. All else apart, git diff reports on the differences between what is in the index (staging area) and what is out in the working directory.

Which shows the benefit of doing git add before git commit. Are there any more such benefits or is git add a common convention that someone should follow (but why?), or doing git commit without doing git add works all the time?

Sorry if I sound dumb. Thanks in advance!!

Answer 1

for a long time I just thought of git as some kind of "save state" (or snapshot) for programming project, in which I can go back in history to previous state (at that time I just git add . then git commit.

But with "staging", now I can "preview" what I want to commit before committing it. I find it easier to think of staging as "print preview" of your commit: you can see what the commit is going to be like before actually committing it (as you can see the printed document before actually spending papers and inks)

for example, I have edited 9 files, 3 files contains new feature, 2 files contains bugfix, while 4 files is not finished (maybe new feature or cancelled feature request)

with staging, I can either:

A. git add those 3 files contains new feature, and 2 files contains bugfix, then commit it as "production ready commit" (ready to be deployed, e.g.: uploaded to public http server via automated means). my other 4 unfinished files will not be included in the commit

B. git add those 3 files contains new feature then commit, then git add those 2 files contains bugfix then make separate commit with different commit message for better tracibility

another benefit in this "staging" is to give me time to "review" my changes one last time. In this "last review" time I can spot errors more thoroughly to prevent mistakes (e.g.: typo)

I know it is not very practical to write git add filename_here for 3-5 times (or more times if you changed more files) before every commit, so I use git clients like lazygit to automate the staging (I just have to click on file name of file that I want to stage)

with lazygit, I can even stage a file partially (e.g.: only 5 lines out of 7 lines changed). This helps tremendously when some changes are not very granular (e.g.: a file containing class definitions is changed, I changed the definition of 3 methods/functions, 2 of those methods/functions is ready to commit and 1 is not ready yet)

other git client that you can use to do "preview and click" staging: sourcetree (windows), gitextensions (windows/linux)

disclaimer: I do not own nor contribute to these git clients above, I just find them very helpful and want to share