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: