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 doesn't “git branch” show anything in my new BitBucket clone?
  • How to manipulate Bitbucket repository with token?
  • BitBucket: how to track a repo's branches in its Wiki repo?
  • How to push Tag to Bitbucket Git Repository in Bamboo from Cake build task?
  • Android Studio - Push failed: fatal: Could not read from remote repository
  • Cannot login to SourceTree
  • 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?

  • Can I use git in local area network?
  • preventing git merge to master branch
  • Trying to set up .SSH keys to connect to Github via Cygwin
  • 'git ls-remote' command parameter to limit the number of returned rows
  • Git reference conflicts between branches (unable to update local branch)
  • How to set --work-tree or --git-dir in smartgit?
  • 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. 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.

    Git Baby is a git and github fan, let's start git clone.