On Monday, December 3, 2012 8:02:26 AM UTC+1, ARSHAD ALI wrote:

> Thank u sir, its mean i cannot push a single file after "commit" but whole 
> working directory will be push to bare repository. I mean GIT works with 
> directories not with single files in terms of push, pull, clone etc."AM I 
> RIGHT SIR"???????

No, that's not right either.

Git works with *snapshots*, meaning whole copies of your working directory 
as they were at a certain point in time.

Imagine you regularly copied your project directory into a backup directory:

$ cd project
$ ls -a
$ README.txt    src/     foo/     etc/   .backup/

If you looked inside the .backup folder, you would have something like:

$ ls .backup/
$ a/   b/    c/    d/   e/

Where each of those directories is a copy, or a snapshot, of what's in your 
project at an earlier date.

$ ls .backup/a/
$ README.txt    src/     bar/

If you think of it like this, then a commit means making a new backup ( the 
next one would be f/ ). A push means synchronizing the entire .backup 
folder (with all snapshots) to another computer.

In reality, Git doesn't use single letters (a, b, c) to identify commits - 
they look more like this: a8f590c2a48a86c3c6ee7cbe7aefe75bb3606b55

Furthermore, Git does a lot of clever internal compression and 
delta-calculation to make those snapshots really fast and small. You don't 
need to know these details though, but if you want to reach into older 
snapshots, you have to use various Git commands, as they're not laid 
straight out on the filesystem like I conceptually explained above.

And it adds the  practical concepts of branches and tags, which are 
basically just aliases for referring to certain snapshots, the latest 
snapshot, and so on. 

This being said, if you want to work productively with Git, you're better 
of reading something more extensive than this to get the basics. Try this 
article which sort of continues upon what I've explained already:



Reply via email to