Commonly used GIT commands for developers

When I started software development, my biggest concern was the source control system. There needs to be more detailed documentation, and senior developers in your team expect you to know this by default. They take it for granted. I started with VSS, SVN, ClearCase, PVCS, and git. It has been git for a while now (7+ years). A blog on source control basics and day-to-day usage from a developer’s point of view would be helpful for new folks entering the software industry. Let us start with the basics of git.

What is Git? Why do we need it?

Git is the free and open-source distributed version control system and the most widely adopted one. The obvious question: what is this version control, and what is a version control system? Version control, also known as source control, is the practice of tracking and managing changes to software code. Version control systems are software tools that help software teams manage changes to source code over time.

If a mistake is made, developers can turn back the clock and compare earlier versions of the code to help fix the error while minimizing disruption to all team members. While it is possible to develop software without version control, doing so subjects the project to a considerable risk that no professional team would be advised to accept.

As software projects grow in lines of code and contributor headcount, the costs of communication overhead and management complexity also grow. A version control system is critical to alleviating the organizational strain of increasing development costs. In addition to being distributed, git has been designed with performance, security, and flexibility.

Before getting to useful commands, it’s essential to know some terms used in git and its meaning. Files in a git repository will be in one of the three states. Modified, Staged, and Committed.

Modified: This tracks the modified files from the working directory.

Staged: This is a snapshot of all modifications done are maintained in a staging area.

Committed: This takes modifications from the staging area and stores them permanently in the git repository.

Day to day basics commands:

1. Repository Setup:

Let us start with the basics. We only sometimes start a new project but contribute to an existing one. For this, we clone a repository or a fork of it in any git server. You will have the URL of the remote repository path.

$ git clone <repo_url>

‘repo_url’ can be located in the local filesystem or on a remote machine (connected via HTTP or SSH).

Example:

$ git clone https://github.com/keon/algorithms

2. Developer configuration:

Another important thing we should do is configure the developer’s user details, name, and email. It will be used to record all of your activities. Use the below commands to set the user name and email.

$ git config — global user.name <name>

$ git config — global user.email <email>

3. Start coding:

Typically, we create a branch for a feature or bug fix we work on. By default, when you clone the repository, we will be in the mainline or master branch. It is always kept clean and reflects the latest production code. We start our work by creating a branch on top of the main/master branch.

A branch is like another copy of the repository. All the changes you make to it will be available in another branch. Typically, you will be working in more than one branch simultaneously. 1 for a feature planned for the next release and the other for a bug fix assigned to you.

Step 1 — Branching: How do we branch and switch between multiple code branches?

To create and switch to a new branch, we should use the following:

$ git checkout -b <branch>

$ git checkout -b payment_integration #here payment_integration is feature

When you run the same command without -b, we can switch to the branch like:

$ git checkout <branch>

Another helpful command with branches is to get the list of all branches available. To list all branches available in your working directory:

$ git branch

Step 2 — View modified and stagged files:

To view the list of files we have modified and stagged, we can use status

$ git status

Step 3 — Staging changes:

Now that we have added or modified some files in your code base, we need to stage these changes before committing these changes to a git repo. You can stage individual files or all files at once.

$ git add foo.js

$ git add . #To stage all changes done in all files in the current directory and sub-directories

Step 3(a) — Un-staging changes / restoring files (Optional if you want):

Maybe you accidentally staged some files that you want to avoid committing. Use the restore command to un-stage your changes.

$ git restore foo.js

$ git restore .

Step 4 — Save changes:

It is recommended to commit your changes regularly at multiple points. You can always squash down your commits before a push. To save all the stagged files, we use the below command.

$ git commit -m “Updated README.”

Step 4(a) — Undoing Commits (Optional if you want):

Sometimes we want to undo the recent commit (which was done in mistake), we can use the following command will undo the most recent commit and put those changes back into staging so you don’t lose any work:

$ git reset — soft HEAD~1

If you want to completely delete the commit and throw away any changes, use the below command. This command is destructive. Once done, we cannot restore changes. Use this command with caution.

$ git reset — hard HEAD~1

Step 4(b) — Squashing Commits (Optional if you want)

Maybe you have four commits (interim commits on a feature), but you haven’t pushed anything yet, and you want to put everything into one commit, so your team members don’t have to read a bunch of garbage during code review.

$ git rebase -i HEAD~4

An interactive text file is displayed. You’ll see the word “pick” to the left of each commit. Leave the one at the top alone and replace all the others with “s” for squash, save and close the file. This will display another interactive window where you can update your commit messages into one new commit message. I like to use “f” instead of “s” because I usually work in such a way that I name my first commit appropriately from the get-go. “f” skips the 2nd interactive file and uses the first commit message.

Step 5 — Pushing changes to the git server:

All the commits we have done are lying in the local repository. To keep it safe and accessible for others, we need to push it to the remote (git server) host.

Use the below command to push a local branch for the first time and subsequent times, respectively:

$ git push — set-upstream origin <branch>

$ git push

Sometimes you may want to push a local branch to a different remote branch:

$ git push origin <local_branch>:<remote_branch>

Step 5(a) — Undo the last push (Optional — if you want):

Once you push something, you shouldn’t overwrite those changes (even though, technically, we can overwrite it). We are supposed to create a new commit that reverts the changes in the last one. The Revert command will create a new commit that undoes all of the changes made in a given commit, then apply it to the current branch.

$ git revert <commit>

Step 6 — Pulling changes from the remote server:

Git pulling is just doing a fetch followed by a merge. Get the latest changes if you know your branch is clean (e.g., master branch). There will be no merge conflicts as long as your branch is clean.

$ git pull origin/feature_x

Step 6(a) — Rebasing:

Rebasing is a way of rewriting history. This command stacks your commits on top of commits that are already pushed up to the server. For example, if the same feature is being worked on by multiple people and everyone pushes changes regularly. We should stack our commits on top of origin/feature_x as below.

$ git fetch origin

$ git rebase origin/feature_x

If you already have a local branch set to track feature_x, then do the following:

$ git rebase feature_x

Alternatively, we can fetch, merge and then stack your changes on top, all in one command as below:

$ git pull — rebase

Another great use of rebasing is just rewriting commit messages. To get an interactive text editor for the most recent commit, do the following:

$ git rebase -i HEAD~1

You can replace “pick” with “r” and change the commit message.

Step 7 — Push feature commits to the main branch:

Once your feature implementation is completed, we must push the changes into the main branch. The natural doubt is how to say the changes are complete. Typically definition of done is with changes approved in peer reviews (for example, PR in GitHub or other tools specific to the company). Once approved, use the below command to take the commit and push it to the main branch with the following commands.

$ git checkout main

$ git cherry-pick <<COMMIT_ID>>

$ git push

Step 8 — Deleting branches (Optional — if you want):

Once your feature is merged into the main branch, you can delete your branch to keep the repository clean. Use the below commands to delete local and remote branches. We should use the -D option flag to force the deletion.

$ git branch -d <local_branch>

$ git branch -D <local_branch>

$ git push origin — delete <branch>

Other useful commands:

Temporary commit:

Sometimes you need to stash your changes temporarily, so you can be on a clean branch or because you want to go back and try something before committing these changes. Use git stash for that:

$ git stash

To un-stash those changes and bring them back into your working directory, use the below command:

$ git stash pop

If you want to apply these stashed changes multiple times, use apply command below.

$ git stash apply

You can stash more than one change at a time and use the list command to get all the stashes.

$ git stash list

To apply a specific stash from that list (e.g., stash@{3}):

$ git stash apply stash@{3}.

View git history

To view the entire git history of the current branch in the working directory, use the log command below.

$ git log

Rewrite the last commit

Replace the last commit with the staged changes and the last commit combined. Use with nothing staged to edit the last commit’s message.

$ git commit — amend

View changes made

Use the diff command to list the difference between the working directory and the last commit.

$ git diff