4

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!!

Shreemaan Abhishek
  • 1,134
  • 1
  • 7
  • 33
  • 3
    Because if you do not use add, there's not much you can do to tell git what to commit (other than asking git to commit all files or specify files when running git commit). – eftshift0 May 20 '21 at 18:20
  • 4
    In general, you use the staging area to set up what things from all things you have changed will be committed... you can modify 50 files and only commit 1 or 2.... you can even go a little further, by using `git add -i` you can even tell git what _sections_ of a modified file will be included in the next revision. – eftshift0 May 20 '21 at 18:21
  • So, to sum it up, I would say: **granularity**. – eftshift0 May 20 '21 at 18:22
  • There are two separate questions you can ask here: (1) How do I manipulate Git's index aka staging area? (2) Why is there a staging area at all? `git add` is (part of, not all of) the answer to question #1; question #2 requires resorting to philosophy, metaphysics, psychology, or some other more fuzzy and/or turbulent area of thought. – torek May 21 '21 at 01:50
  • The key to keep in mind, though, is that `git commit` *does not use what is in your working tree*. It commits what is in Git's *index* (or staging area). So something has to copy from working tree to staging area, before the commit happens. Using `git commit -a` runs a separate *copy to staging area* step for you first, but there are some flaws in the way it works; you sometimes have to use `git add`. – torek May 21 '21 at 01:54

2 Answers2

2

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)

lazygit preview

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

Kristian
  • 2,456
  • 8
  • 23
  • 23
1

git-add - Add file contents to the index.

The "index" holds a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit. Thus after making any changes to the working tree, and before running the commit command, you must use the add command to add any new or modified files to the index.

The content to be committed can be specified in several ways:

by using git-add1 to incrementally "add" changes to the index before using the commit command (Note: even modified files must be "added").

https://git-scm.com/docs/git-commit

Hamada
  • 1,836
  • 3
  • 13
  • 27