Rephrasing Git : Easiest possible guide (part 2)
If you haven’t read the previous part please go and read it. In the last part, we talked about setting up almost everything needed to start. I will keep my promise of explaining each and every command. The explanation would be in as easiest language possible. Before moving on further I would like to tell you about this article’s agenda.
The above words are normal English words and works similar to as they sound. Don’t worry if it was all self-explanatory then what would I be doing here. So, let’s dive in.
Staging : This is the part where you decide which files you are going to take further. Suppose you are working on a project with 10 files and currently you are updating code only in 1 file. Then you leave other files as they and stage only one. Just remember whatever you stage will only be tracked by git i.e. checkpoints for only those files will be created. To stage use the git command ‘add’. It’s syntax is:
git add <file_name>
Generally, what lousy developers like us (yes! some people say developers are just a bunch of professional googlers. LOL) stage all the files in the project. This can be easily done by:
git add .
. (dot) represents the current directory path. So, by writing the above line you track all the files present in the current directory. By performing this step you have simply told git that please keep track of these files as they are important for my project.
Committing : Once you staged (added) the files then you are ready for making the checkpoint. Yes, you heard it right. I have been telling about making logs, saving checkpoints and blah blah blah. So, here I present to you the most important step. Committing. The command for making a commit is:
git commit -m "<your_commit_msg>"
“-m” tells that you are providing commit message. Please try to keep these messages of not more than 5 words ( not compulsory). The commit message should be such that it is self explanatory. Others should also get what you did in this project.
Pushing : This is the final step in completing one cycle of your git journey. pushing means to upload the code on your online repo. Remember this online repo’s link is already saved in your remote. Once you push the code all your commits are saved online. The command for pushing is:
git push -u origin master
The syntax for push is:
git push -u <remote_name> <branch_name>
Saw some big words? Don’t worry! I will explain everything. “-u” here represents upstream. It tells git that “push all the new files or code updated, don’t worry about any files which are deleted in local repo”. Next thing comes is remote. I explained it many time before but once again. Remote holds your online repo’s link. Coming to branch, a single project can have many branches. I will be explaining about branch in detail in coming articles. By default ‘master’ branch is there. Instead of writing full command you can write ‘ git push’ only. But, it’s not recommended.
Logs : Whenever you make a commit your log gets updated. To view the log simply write the following command.
Status : As the name specifies, status represents the current state of repository. which files are untracked, which are uncommitted, how many commits your local repo is far/behind online repo etc. The command is :
The log and status commands will become most used command for you.
Reset : I have talked about making checkpoints and all a lot. We can come back if we mess up something. So, here ends your wait. Reset makes you go to the previous commit. You do it and you are back to your safe haven. Voila! There are two methods to use reset.
Using commit SHA value: whenever you make a commit. A corresponding SHA value is generated. Try ‘ git log’ command again. You will see something like this. (tip: press ‘q’ to exit this window)
You can see, that you do have something called HEAD here. HEAD points to the state of directory where you currently are. Now copy the first 7 characters of your commit hash value ( yes that long alphanumeric string only). You can copy more but 7 is sufficient. Now comes the main command.
git reset <copied_commit_hashValue>
eg: git reset 5db3258
The other method is by simply counting how much behind you want to go. Just count the number of commits and :
git commit HEAD~<number_of_commits>
eg: git reset HEAD~3
Now your head pointer is moved to the previous commit (as per your wish). Final step is checkout.
git checkout .
checkout brings your whole directory to the state where your HEAD is currently pointing. See the magic. Now try this for 2 to 3 more times. Try deleting the file and then going back to the previous commit.
Huff!! lots of knowledge. I know that at first, it’s hard to grasp all this in one go. Don’t worry!! try reading it again. Write a response if anything is not clear to you. Your feedback is very much welcomed. You can also find me on LinkedIn and GitHub. Upcoming articles would be more on advanced topics. Till then stay in stay safe.