It’s been a long time since I wrote my last blog, maybe because I didnt get much time to work on my project recently, or because of too much ‘temptation from social life’ in college, or maybe because I just simply could not figure out how to actually start! Honestly speaking I guess it was because of the last option, I was trying to understand everything at once, when actually I didnt even know the basics or the root of the whole concept with which I have to be dealing with. Thankfully, I was suggested to take a few steps in learning first, and first understand about what “git” is all about
Well, so that was my motto… learning everything about git. So I opened up my e-book called “Pro Git” and started reading continuously from the first chapter. It was a really nice book, and the best thing about it was that everything was explained so elaborately that it would be pretty difficult for some one to NOT understand a concept 😛
Well, so I kept reading.. Actually I was having absolutely no idea about this project-handling and version controlling systems, leave out distributed vcs. So it was really interesting to read something which was entirely new to me.. Well, this, is what I learned from the book:
Git, is nothing but a platform, in which people can “keep” their projects, and handle the changes made to the files, efficiently.. Its more of like a virtual desk in which you can do your work, and its perfectly suitable for any large project you want to do. We can “clone” into a git repo, and create directories in our home computer’s hard drive, change and do any modifications to them, and then “add” them to the “platform”.. Actually I should not use this term platform any more, as it is officially called the “staging area”. Whatever, the thing is, we can create, modify, delete or make ANY changes to the files present in the hard-disk (officially known as the “working directory”) and when we are satisfied with it, we can simply “git add” them to the staging area, ready to be committed later. Now, after doing a part of the work, if you feel that that portion of the work is completed succesfully and no further changes would be needed later, then you can “commit” them by giving a suitable message telling the readers what exactly you have completed. Now this committing is I guess nothing but saving gedit file I guess, the only difference being that in this case, you’re saving a PROJECT, not a FILE 🙂  Another thing which I learned is that in git, when we save a part of our work by committing, they are not saved as “differences”, but are instead saved as SNAPSHOTS! The whole picture of what the condition of your project looks like, is taken a snapshot of, and it is saved. Infact, if a file is not changed, that file is not even considered and in the snapshot it can be seen for itself, the state of the file I mean. Quoting from the book:
The basic Git workflow goes something like this:
1. You modify files in your working directory.
2. You stage the files, adding snapshots of them to your staging area.
3. You do a commit, which takes the files as they are in the staging area and stores
that snapshot permanently to your Git directory.
I have also learnt about how we can clone into an existing directory, thus creating a directory in the hard drive of our computer thus making it much easier for us to work on the project while we are not online. In fact, there’re many things that can be done completely offline via git, but those which cant be done by other vcs’s. We can also check the status of the files in my repo by the “git status” command, and also make git to “track” files by “git add”-ing the file we want to be tracked. Basically what happens is that when we “add” the file it simply comes to the staging area! Another important thing is there: that even if we DO add a file, if we modify the file later.. while commiting, it will NOT take snapshot of the modified version but take the previous version only, since i did not “add” that file after modifying it.. smart! 🙂
Also, sometimes if we find that the command “git status” is too vague, then we can use the “git diff” command. It will show you the exact lines added and removed. There are many other formats of showing different kinds of info on what is present in the staging area and what not, but i’m not going into that!  Now let me come to the main thing.. Committing your changes. For that we can simply just do a “git commit” command which will take a snapshot of the current condition of the satging area.. and open a vi editor where it will ask for your message, OR, we can give that message in the command line itself by using the “-m” extension with the command and the message writing in double-quotes 🙂 We can also skip the staging area completely by providing the -a option with it, thus staging every file that is already tracked before doin the commit, letting yo skip the git add part completely. Now for removing files toh we can simply do “git rm” followed by the filename, and the file will be deleted ffrom the staging area, that’s no big deal..
Coming to the Commit History, we can view it using “git log” command which will show clearly the author, email-id, the MESSAGE, along with the date and time as well, in a nice structured manner. Actually I guess THIS is the area in which I need to focus on, for my proect!
Anyway, I guess I did cover up with the basics of Git, and must be able to work on it now without any difficulty. I have got the basic understanding about what it is, so now Im just gonna skip to concentrating on my main project, and referring to the “Pro Git” book in case I find something I would need to know in order for me to work on my project
sanjibandotme 