Does git checkout update all files?

Newb question, I want to make sure I understand this.

When I git checkout <revision>, does this return the entire project to its state at that moment, or does it only recreate the files changed in that particular revision?

  • How to make 'git not ignore' certain file extension in nested folder structure?
  • `git` and `less` integration in OS X terminal: prevent writing output of `less` to tty
  • Using git svn on a repo created with svn2git
  • Is it possible to setup git merge for automatic resolving? (git rerere)
  • Alternatives to GitHub Pages?
  • Can I add a git remote for all users?
  • For example: If my folder was completely empty besides the .git repo, and I git checkout master, will the resulting files be the project in its entirety, or only the files changed in the most recent commit?

    I ask, because I am checking out my project at various points (starting from the beginning), and instead of the project slowly growing in size as one would expect, the size of each checkout is varying quite a lot.

  • Git Clone Failure
  • Force add despite the .gitignore file
  • How to discover a file is changed in GIT during a push
  • .gitignore is whitespace sensitive?
  • How do I tell github that I made all of the commits pushed from my laptop?
  • git submodule init does absolutely nothing
  • 2 Solutions collect form web for “Does git checkout update all files?”

    When I git checkout <revision>, does this return the entire project to its state at that moment, or does it only recreate the files changed in that particular revision?

    If your working tree and staging area are completely empty (besides the .git subdirectory, of course) and you run

    git checkout <revision>
    

    then your working tree and staging area will perfectly reflect the contents of that particular revision.

    On the other hand, if your working tree is not empty when you run git checkout, what happens is much more subtle, and may be broken down into three cases:

    1. The checkout is not problematic and Git carries it out without batting an eyelid: the contents of that particular revision get copied to your working tree (and overwrite stuff already present there, if needed). Or
    2. The checkout, if it were carried out, would result in a loss of local changes; therefore, Git (under the assumption that you didn’t use the -f flag) tells you off and aborts the checkout. Or
    3. A more complicated situation may arise in which stuff is only partially checked out, and some local, uncommitted changes are kept in your working tree and/or index. More details about that situation can be found in my answer to Why are unstaged changes still present after checking out a different branch?.

    […] the size of each checkout is varying quite a lot.

    Are you taking into account untracked files? Did you commit, then later remove large files? On the basis of the information given in your question alone, we can do little more than hypothesize about the reason why the size varies a lot.

    From the documentation: “Updates files in the working tree to match the version in the index or the specified tree. ” In the case of your example, it will return the repository to the state at the time of the checkout in its entirety.

    However as Jubobs pointed out there is a difference in behaviour if you have made any changes to the state of your repository since your last checkout. His answer is more comprehensive than mine if this is the case.

    Also note that this will only apply to files that are tracked by git, so any other files you have lying around will not be affected.

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