Are you a software developer? If so, I am sure you know about the version control tool git. For those who have heard of Git but are not sure what is it and why we need to learn it, Git is a version control tool used to keep the version history of our applications. It just doesn't help in saving the history of various versions of the code that we have committed(deployed), but it provides a lot of features to play around with these versions. Most disastrous production glitches in applications could be resolved by restoring previous versions, all thanks to git. It is also popular for the collaborative feature, where multiple developers can contribute to the project(application) without worrying about code conflicts. Today, we would know some popular git commands that you must know as a software developer.
1. git init
When you want to create a new project on your local machine, you could create it using boilerplates available that can be installed using any package manager like 'npm' or 'yarn'. And when you decide to have version control for the project, you will need to initialize an empty git file onto this project. This ideally starts reading the changes in the project as you start making them and keeps these changes ready to be staged. The command to be used here is :
git init
This would give a message as, ***'Initialized empty Git repository in C:/users/shravaniroy/desktop/newProject'
If you have git already initialized earlier in your project, it would give the same message pointing to the existing git repository.
2. git clone
This is the command used to clone an existing Git repository on your local machine. It creates a new directory with all the objects from the remote repository. The default branch it points to is the 'master' branch. Say you want to clone one of my public repositories, where I implemented a web page to display the git jobs using Git's open API. You can find the repository here. Here is the command to clone the above repository.
git clone https://github.com/ShravaniRoy/recreategitjobs.git
The above command creates a new directory in the directory where you have opened the command prompt to run the above code. From here onwards, we have to navigate to the new directory to run the below commands.
3. git status
This command is used to check the list of files that have changes in the project. These changes could be anything, could be a small change in an existing file to adding a new file in the project. As you make these changes in the project, you will observe that the existing files are marked as M (Modified) and new files added are marked as U (Untracked). However, the node modules are excluded from the tracking by default. This is set in the .gitignore file. You could add more rules to this file to control what is to be tracked and which files to be ignored. Here is an example of how it displays these changes.
git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(Use 'git reset HEAD <file>...' to unstage)
modified: index.html
modified: css/styles.pcss
4. git checkout
Usually, in any real-time project development, it is suggested to maintain different branches. You can either have different branches for different features or have a different branch for every individual contributor. You can prefer to go with the former approach when there are limited contributors. Perhaps, it usually depends on the architect/lead. To create a new branch based on an existing branch, we use the following command.
git checkout -b <yourNewBranch> <existingBranch>
//example 1:
git checkout -b productsFeature master
//example 2:
git checkout -b productionDefectFixes prod/v1.0.2
If you have observed, I have named the branches for the purpose of creating them. I can't emphasize enough the importance of naming conventions throughout the developer journey. One more thing about the above command is that it not only creates a new branch but also switches to that branch. So you might have guessed it right that the same command is used to switch between branches. And in order to know which branch are you currently working on amongst all the branches you have on your local machine - use 'git branch' command. Let me show you how it displays that below.
git branch //our command
*master
productsFeature
git checkout productsFeature //command
Switched to productsFeature
I use Visual Studio Code for work and I have observed that at times there is a delay in the changes that we make reflected in VSCode. Hence, I make sure to check the branch by using 'git branch', before I make any commits. We will know more about commits in the next section of this blog.
5. git add
Most of these Git options are available as inbuilt features in most of the IDEs. Be it VS Code or Eclipse or any other IDE, have the git commands as features/buttons. I have observed that most developers are used to using these IDE tools instead of direct git commands, which sure makes our lives easy but it is good to know the commands to understand how Git works. Anyways, so this command helps in staging all the changes or the files you choose, to commit. Let us see how.
git add .
//the above command adds all the modified or untracked files to staging
git add package.json
//the above command would stage only package.json amongst all modified files.
6. git commit
During project development, we would have different sprints in which we deliver a feature and while developing a feature pack, we usually work on a daily base and might have to check-in our code every day. So, instead of leaving it to timestamps, it is ideal to have some description of what we have developed for every commit. Hence, the message attribute of the commit command. Commits are like landmarks. Having a descriptive commit is a good practice. It has to be human-understandable. Let us look at a sample below.
git commit -m "routing setup done"
git commit -m "defect 321100 - radio button alignment fixed"
git commit -m "customer session establishment - jira story 123213"
Like the above commits are understandable that the code that is committed in respective commits refers to setting up routing, fixing defects, and a feature pack. Naming your commits will help you and your team in the long run.
7. git push
Once you have a few commits(or one commit) that you want to merge to the master/main branch, you can use this command to push your changes to the remote branch and you are ready to raise a PR for merging it into the main branch. We will discuss PRs in a separate blog. Let us see how this 'git push' command works.
git push // from the branch which has been set to upstream earlier.
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Writing objects: 100% (4/4), 209 bytes | 104 KiB/s, done.
.
.
.
//If you are trying to push your local branch for the first time use the below command.
git push --set-upstream origin <yourBranchName>
//you could get a message something like below
Branch 'productsFeature' set up to track remote branch 'productsFeature' from 'origin'
8. git fetch
This is an awesome command that talks facts. Many times when I was informed that there were changes shipped by other developers in the team, I used to check using 'git status' command. This used to always say that "your branch is up to date with the remote branch from 'origin'.". And then I learned about the command 'git fetch' that reads the changes from the remote repository without actually downloading them. This allows you to read any new remote branch.
git fetch //straight forward
9. git pull
This command is similar to the previous command 'git fetch', differing in reading the remote changes. While 'git fetch' reads the changes from the remote repository and displays the list of changes, 'git pull' on the other hand downloads these. changes onto your local machine. This would show the changes in VS Code. This is ideal in case when you have expected changes, whereas fetch helps in knowing other's changes before you take any further step, mostly in a distributed team that works asynchronously. This is also a straightforward command.
10. git merge.
From the above commands, we have learned how to take the latest code on your local machine. However, there are pretty good chances that you and your peer had worked on the same file and have committed to a common branch. In this case, merging the remote branch with your local branch would create conflicts. As VSCode helps in retaining both - your changes and incoming changes, it lets you accept any one of them from each file that has been identified with conflicts. So, resolve them to continue. Let us see some examples of it below.
//Let us say I have made changes in routes.js file adding a route for the products page
//And my teammate had added another route for the checkout page
git branch
*productsFeature
master
git merge origin/master
// this merge command would pull latest code from remote master branch on to local //productsFeature branch
Most powerful:
Yes, there is a git command that is extremely powerful and developers try not to get to use it. I used it in my early developer days when I messed up by committing some unwanted or wrong changes. 'git revert' is the command that works on the forward-moving operation that lets you undo changes in a safe mode. When you have a commit that you want to revert, use the command 'git revert' to undo this change without actually deleting the commit. This will for sure create another commit with the changes as reverted, yet it is part of the history and you cannot delete something that happened. It remains in history. To revert the uncommitted changes use 'git reset'. This is a cool command that lets you undo local changes to the state of a Git repo.
Bonus.
- git stash Say you have made some changes in your branch and you have more work to do, yet you have noticed that there are some new changes in the remote branch. In order to pull the latest changes, Git wouldn't allow you to do so without committing your local changes. Perhaps, your changes might not be as major as they could be marked as a commit. Don't worry there is a space in Git that lets you park these changes without committing but stashing them. It is of type stack. So, you could either stash your changes with a name/tag or just stash them without any tag. This allows you to park the changes and lets you get them back by popping them from the stack.
git stash
git pull
//resolve conflicts if any
git stash pop
This is a great tool when you want to switch between branches. There could be days when you might have to juggle between features based on shuffling priorities from the business.
- git worktree This is the most powerful tool that Git offers to developers. Ever since I learned this command, I feel so skilled. I can now compare two branches without having to switch between them. You can add n number of branches to the existing worktree and when done with your work, you can remove those branches from the worktree. Let me show you how.
git branch
*productsFeature
cart
master
// syntax - git worktree add <path and branch>
git worktree add ../cartBranch
//When you want to remove a branch from current worktree
git worktree list //this is to check the list of branches you have on the current worktree.
git remove ../cartBranch
You could do a lot more using different attributes of these Git commands. There are many more commands, I just listed those I use often. I recommend you learn more from the official documentation of Git.
I hope this was helpful. Thank you. Happy learning!