> ... Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.

I understand, but my point is that the snapshot that you take is based on what you **stage** and then commit not necessarily what's on your disk. You tell Git what to commit. `-a-` is just a shortcut that says stage and commit everything in one step.

Personally I think the big difference - and perhaps learning curve item - is that Git doesn't have the concept of file locks where files are 'checked out', but rather treats all committed files as a state snapshot that is compared to another snapshot when merging. This changes how you use Git compared to classic SCC like SourceSafe - in many ways it's so much better, but it does require adjusting in how you manage changes. In collaborative environments you have to make sure to commit small and commit often, and pull often to ensure you don't get very large commits causing merge conflicts.

+++ Rick ---

>>>to keep it short
>>>https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F
>>
>>I think you're confusing the inner workings of Git with the over all philosophy. Git's internal workings as a diff engine that only stores differences has no impact on how you manage your source control usage.
>>
>>Unlike SourceSafe or SVN, Git only stores changes. But the changes you store are up to you to decide and there's nothing that suggests that 'saving everything' is the way to go. The reason to break out files is not for Git benefit, it's for me to provide a reasonably trackable audit trail of changes that aren't just a boatload of unrelated incidentally changed files, but rather those things that are relevant for a given fix or new feature. Occasionally then I need an extra commit for 'project maintenance' to update incidental files that don't fit into feature fixes.
>
>Hi Rick,
>
>It's just for my understanding. No argument.
>Just out of the doc above.
>
>... Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.
>
>To me this means to think in the project as a whole unit, rather then file by file.
>I've started git with this, and other stuff I can't remember any more. And I found it here and on other places as the clear idea behind git: Think in project, not in file. Do a task, not a change.
>One can use it file by file, shure.
>But from what I have learned, this is very fast very complex. The simple approach possible would become frustrating.
>Maybe this is why I here all the time about the complexity of git - from people rarely have a branch second to master.
>
>I was used to VSS before, and I spend some time to adjust myself to it, but it works like a charm.