5 Useful Git commands you should know 🚀

Git plays a vital role be it while working in a company 👩‍💻or collaborating 🤝with developers for our personal projects .

I’ve tried to sum up few Git commands that saved a lot of my time ⏰and efforts during my Internship in my First year of college.🤗

Few handy git commands that will help anyone work efficiently and save time.✨

1.The very first problem I faced is to switch between multiple branches when I am told to work on different pieces. It is indeed a bit tricky because we don’t want the changes made by us in the current branch(say A) to be carried forward to any other branch(say B). As a result we commit the changes made in A and then switch to B. However, after the work is done in B, we may not want the committed changes in A, which was solely done to switch branches. In this case , the following command is quite useful .

$ git reset HEAD~<no. of last commits>

2. We would definitely need to know “git log” which lists the commits made in that repository in reverse chronological order; that is, the most recent commits show up first. As we can see, this command lists each commit with its SHA-1 checksum, the author’s name and email, the date written, and the commit message. It helps us to keep a track of the repository without visiting GitHub.

$ git log

The best option -p that is available about committed logs is the patched output, which limits the displayed log to the specified number . It will limit the output and display the number of commits that most recently occurred.

$ git log -p -<no. of log entries we want>  

The --stat option prints each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.

$ git log --stat

3.Sometimes, we need to compare between two commits in the same branch so that we can fix issue(s) that occurred after the latter commit of the two . This command is very useful .

git diff <commit_Id_1> <commit_Id_2>

The respective commit Ids we would like to compare is fetched by using “git log” .

4.The difference between

$ git push origin <branch>

and

$ git push --set-upstream origin <branch>

is that they both push just fine to the remote repository, but it’s when we pull that we notice the difference.

If we do:

$ git push origin <branch>

when pulling, we have to do:

$ git pull origin <branch>

But if we do:

$ git push --set-upstream origin <branch>

then, when pulling, we only have to do:

$ git pull

So adding in the --set-upstream allows for not having to specify which branch that we want to pull from every single time that we do git pull.

5.Sometimes we may have to work on a branch that is already created and pushed into the main code base. The best way to deal such situations is to use fetch command and not clone. This is because clone command will generate the entire codebase within the existing folder, which is not what we want.

On the other hand, the fetch command will include the required branch in our remote directory without cloning the entire folder.

Here, the branch is changed to testing which is exactly what we want.

Thank you .That’s all for this blog. Hoping to bring you guys more useful content in the next!! 😀