Git add: Why do I have to manually specify which files to commit?
I am just learning how to use git. So, I have created a new repository, which contains a file “foo.txt”. To add this to version control, I ran
git add foo.txt. Then, I made some changes to the file, and ran
git commit. This then seemed to update the repository.
I then made some further changes to the file. After this, I ran
git commit again. However, this time, it returns with
no changes added to commit. But if I then run
git add foo.txt before running the commit, it does make the changes.
Why is it that I seem to have to
add my file each time? I want to be able to just run
git commit after my changes, without having to tell git which file I have made changes to.
Is it normal that I have to manually specify the files to commit? Or am I doing something wrong? Can’t I just tell git that every time “foo.txt” is changed, I want it to be added to the next commit?
3 Solutions collect form web for “Git add: Why do I have to manually specify which files to commit?”
git add does not work the way
svn add works, its purpose is not “start tracking this file”. Its purpose is “stage this content for the next commit”.
If you happen to run it on an untracked file, git will start to track the file, and include the file’s current contents for the next commit. It is just tracking the contents though – the fact that it’s a new file to track is more or less a side effect of adding the file’s contents.
If you modify a tracked file, use
git add to add the contents of that change to your next commit.
If you then modify the file again you will need to
git add again to stage the new changes you made.
You can also add partial changes using
git add -p. That will let you stage only some changes you made to the file, but not add other changes. (It will chunk the changes up similar to how
diff would, and ask you if you want to add or ignore each of the chunks.)
This is all in service of flexibility. You can very finely control what changes are added to a commit, exactly how you prefer. Or, you can
git commit -a and just sweep up everything at once, if that is how you want to work.
There is a difference between the staging area and a committed snapshot in git. In your explanation when you used the
commit command, you actually committed the version of
foo.txt as it was when you used the
add command. In short
add only stages a file ready to be committed. The
commit command is required to save the snapshot.
There are times you have made changes to multiple files, but want them to be in different commits, the staging area lets you choose what to commit and when, rather than just dumping everything in one go. There are other uses, but this is probably the easiest to understand as a beginner.
Not so useful if you are just saving snapshots of a codebase though. https://git-scm.com/book/en/v2/Getting-Started-Git-Basics has a nice guide to starting to use git
Because all changes to all files will not always belong in the same commit.
For example, if I’m refactoring a homepage while also working on a new feature for message-sending between users, these changes have nothing to do with one another. Therefore my commit for the homepage might have a message like
"Refactor homepage to include cool photos" while the message-sending features commit might have a message like
"Implement message-sending functionality between users".
Also keep in mind that you can, and will likely often need to, store only certain parts of a file in a particular commit, and store other changes to the same file in a separate commit.