We help IT Professionals succeed at work.

git, understanding

Medium Priority
Last Modified: 2015-03-05
Reading from http://git-scm.com/book/en/v2/Getting-Started-Git-Basics I get the following:

Question: Could you please take a look at the following to make sure I have it right:

a. When commit is issued for File A for the first time, a snapshot of File A is saved locally as Version 2.
   (Q_a: Is this accurate?)

b. At Version 3 if no changes made to File A but commit is issued, a link is saved to the previous File A at Version 2.

c. All these file snapshots or links are on the local computer?
  (Q_c: Are each of these snapshots a complete file to that point or they only contain the changes?)

d. These version could be accessed by other team members.
  (Q_d: If they are on a user_1 computer, how the other users get access to it?)

I am continuing to read this link but want to make sure I have it down up to this point.  
Watch Question

IT Business Systems Analyst / Software Developer
Top Expert 2015
a) I think your thinking is correct, but I'll just make one correction to what you wrote...

When commit is issued for File A for the first time, a snapshot of File A is saved locally as Version 2
The first commit issued is what actually created Files A, B & C at Version 1, so I think you might actually be talking about the second commit causing a snapshot of File A as Version 2

b) Essentially, yes

c) Generally you can think of each snapshot being the full content (however, internally Git may optimize its storage using deltas to other files, but even these deltas don't necessarily relate to how the file changed over history)

d) Having others user access can happen in a number of different ways... You could "push" some or all of your repository to a remote git repository, or you could in some way organise your repository to be accessed (as a remote) from the other users computer
To add...

b) If you think in terms of Unix-based systems where directory is a file, then Git creates tree nodes (equivalent of directory files) that are also stored in repository. If anything changes in a subdirectory of your project, then new tree node must be created. The root tree nodes are captured to a commit node. See images at http://git-scm.com/book/en/v2/Git-Internals-Git-Objects

c) Yes, everything is inside the .git subdirectory of your root directory for the project. Unless you edit video or some other binary files, the Git is still very disk-space efficient. Think as if your project sources would be ziped. But think the way that a new change adds only a small zip file that is related to the changed file. This way, fear about Git eating your disk space is not the way you should feel. As mccarl wrote, deltas are created when data is "garbage collected".

d) If a user has access to your directory with a git project, he can clone it without problem. However, when sharing the project, you should create a bare repository elsewhere. The bare repository does not contain the working copy of the (unpacked) files. Its content is similar to the content of your .git subdirecory, and it is named MyProject.git by convention. Usually, the people clone from that shared bare repository, or give it a name upstream by convention and adds it as a remote repository.

Explore More ContentExplore courses, solutions, and other research materials related to this topic.