Basic Git commands every novice should know
We’re all familiar with the importance of version control systems in today’s world. Nobody wants to go through the hassle of debugging an issue, and getting the code to work perfectly, only to mess it up while making some tweaks.
When it comes to version control systems, who isn’t familiar with Git? One of the most widely used version control systems out there! Git is an open-source distributed version control system that assists developers in keeping track of their project changes.
Speaking of the significance of Git, today I will walk you through some basic Git commands that could save you time and make your work feel effortless. Let’s go…
Setup
Setup Credentials
While starting up with git one of the first things to do is to set up your credentials.
# --global will set the credentials globally in your system
git config --global user.name "Your Name Comes Here"
git config --global user.email "you@yourdomain.example.com"
Note: If you use a web-based hosting service for Git repositories i.e., GitHub, GitLab, etc. Specify those credentials in git.
Setup Default Primary Branch Name
Both Git and GitHub have recently undergone some changes. While the primary functionality remained the same the convention of calling the primary branch “master” has now shifted, and newer repository primary branches are called “main”.
Depending on your organization or personal preference, if you need to set your default branch it can be done as follows,
# setup default branch
git config --global init.defaultBranch main
Basics
Cloning an Existing Repository
If you’re using a web-based VSC service, you’ll need to clone the repository to your computer to start working.
# clone the remote repository on your system
git clone https://github.com/user-name/repo-name.git
Initializing a Repository
If you’re getting your project started locally, you’ll need to initialize Git in your project to utilize the Git version control system.
# initialize a git repository
git init
Stage Changes
After you’ve initialized or cloned a repository, you can begin making changes to the code. When you’re ready to save the changes, you need to stage them.
But what is staging?
As per the official guidelines, Git has three stages: modified, staged, and committed.
- Modified means that you have changed the file but have yet to commit it to your database.
- Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
- Committed means that the data is safely stored in your local database.
So when you are done with the changes, stage them.
# to stage a specific file; always mention file_name with the extension
git add file_name.ext
# if you want to stage all changes
git add .
# you can also stage a folder
git add folder_name/
# wildcards can also be used
git add *.ext
Commit Changes
Staged changes are not secure, meaning that staging doesn’t create a version in the history. It simply acts as a stage between your commits and local changes. To save changes in history, you need to commit them.
# commit the changes and specify the commit message by -m
git commit -m "commit message goes here"
# you can also style the commit message as a summary and details
git commit -m "commit summary" -m "commit message goes here"
You can simply use git commit and specify the message later in vim. However, I prefer using -m as it saves me some time.
Changing the Commit
If you forget to add some files to the commit, or you want to make more changes to the files after committing them, don’t worry. You can simply amend those changes in the commit.
Just make changes, stage them using git add, and then amend them.
# add changed to last commit
git commit --amend
Check Status
Have you ever had a moment where you suddenly forgot if you saved a file while working? This can happen while using Git too. For those moments, we have status command.
# check the status of all files
git status
It will show you the status of all your files, so you can quickly get back to your work or save the changes you haven’t saved yet.
Check Difference
The git status shows you the status of all the files, but if you want to compare the content of a file, you can check the difference.
# check the difference between all files
git diff
# check the content of a specific file
git diff file_name.ext
# check the content of a specific folder
git diff folder_name/
You can also view staged changes. Remember: staging contains what will go into your next commit.
# check staged changes
git diff --staged
# check the content of a specific file
git diff --staged file_name.ext
# check the content of a specific folder
git diff --staged folder_name/
View the Commits History
After making numerous changes or collaborating on a remote repository (such as GitHub or GitLab), it often becomes crucial to review the commit history to track the progress. Git offers this functionality through logs.
git log
# you can also see just the summary of logs
git log --oneline
# you can also see the ASCII graph of the branch and log history
git log --graph
Now, Git Logs requires a separate article. However, I am sharing the commands that will be useful in many situations.
In addition to the above commands, you may find the limit options to be helpful.
- - Show only the last n commits.
- -- since, -- after Limit the commits to those made after the specified date.
- -- until, -- before Limit the commits to those made before the specified date.
- -- author Only shows commits in which the author entry matches the specified string.
- -- committer Only show commits in which the committer entry matches the specified string.
- -- grep Only shows commits with a commit message containing the string.
- -S Only shows commits adding or removing code matching the string.
Pushing Changes
If you are working with a remote repository, remember that all the commits you have created using Git are just saved in your local system until you push them.
# push the changes to the branch
git push origin branch_name
Fetching Changes
When working with remote repositories, you might need to fetch the changes; repositories, and tags, that other developers have committed.
# fetch changes from origin
git fetch origin
Creating Tags
Tags come in handy when you want to highlight an important point in VCS. The most common use case is marking the release of the project.
There are two types of tags, Annotated tags and Lightweight tags.
Annotated tags are stored as complete objects in the Git database and include details such as the tagger’s name, email, and date. They also have a tagging message and can be signed and verified with GNU Privacy Guard (GPG). These are the recommended tags for significant points like releases.
# create an annotated tag
git tag -a v1.4 -m "initial release - version 1.0"
On the other hand, Lightweight tags are simply pointers to a specific commit and can be used for various other purposes.
# create a lightweight tag
git tag v1.4-lw
You can also verify the content of tags using the show command.
# see the content of a specific tag
git show tag_name
And once you are done, you can push the tag(s) to the remote repository.
# push a specific tag
git push origin tag_name
# push all local tags
git push origin --tags
Furthermore, you can list, delete, and checkout tags as needed.
# list all tags
git tag
# show additional information of a specific tag
git show v1.4
# delete a tag from the remote repository
git push origin --delete tag_name
# checkout to older version (tagged time) by creating a new branch
git checkout -b new_branch_name tag_name
Creating Aliases
Last but not the least, aliasing. Yup, you heard it right. Git allows us to create aliases for commands to make things easier using the git config command.
# aliase commit as cmt
git config --global alias.cmt commit
While there are numerous use cases for this, my personal favorite is aliasing the long commands associated with tags.
# aliase diff --staged command
git config --global alias.diffs 'diff --staged'
So now, whenever I need to execute the git diff --staged I can simply call git diffs.
And that’s all for today. While there’s much more to explore regarding logs, tags, and branching, we’ll save that for future articles since this blog is meant for beginners.
If you found the article helpful and learned something new, please give it a like. Feel free to share any suggestions in the comments section.
Top comments (1)
Hi Samar F. Jaffri,
Top, very nice and helpful !
Thanks for sharing.