Git: git status command

git-status is a basic git command which shows current state of the working tree/ directory.

Introduction

As you have probably noticed, a nice thing about Terminal is that we can see the history of commands that we have already executed. They do not go away when we run another Git command. Now this is great for remembering the steps taken to reach our current state, but as you can see, the majority of our screen is taken up with our previous Git commands. This can leave things a bit cluttered, especially when using help guides or similar commands that respond back with a lot of information.

It is often nice to clear this information out and start with a clear Terminal window. We can do this by typing the clear command. This clears out our window and moves our command prompt to the top of the screen. Now, we did not erase this command history. We can always scroll back up to view our previous commands. All the clear command does is move this history out of view.

 $ clear 

The origin is the repository version that sits in our remote repository which is usually, GitHub repository. Since we just pushed our local repository to GitHub, these two repositories, our local repository and the remote origin repository on GitHub, should be the same.

But with Git, you do not have to guess or try to keep track of the current state of your project or files. You can check the status of your project at any time by using the git status command.

If we type git status in our command line, Git will respond back with a few lines of information.

Example of git status on our Rocket project code is as follows:

opengenus:~/workspace/opengenus_project (master) $ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

        modified:   course/settings.py

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

        modified:   db.sqlite3
        
opengenus:~/workspace/opengenus_project (master) $ 

1. The first line is stating the branch that we are on, which is the master branch.

Now, back in a previous module when we initialized Steve's Git repository, Git created a master branch automatically. A branch in Git is a lightweight movable pointer to your project at a specific point in time. Now since our two repositories are in sync with each other, our local master branch is equal to the origin master branch. This default branch that was created is called the master branch. If you're a little confused on the idea of a branch, don't worry, we're going to cover branching in detail in the next module, but for now just understand that when you initialized your Git repository, Git created a branch called master. And when you make changes in Git, you make them on a specific branch. Now branching is a core concept in Git, and a feature that adds a lot of value by allowing many different types of workflows that can involve many different types of branches. But at least for right now, we'll keep things simple and make all of our changes directly on the master branch.

2. The second line in the response mentions that our branch is up to date with the origin master.

Now this one is pretty easy to understand. It's saying our local branch, again, which is master, is up to date with the origin master branch, the one being hosted on GitHub. And the third and final line is saying that there is nothing to commit, and that our working tree is clean. If you remember from the last module, we haven't modified any files, so there are no changes yet in our working directory, and nothing yet that has been staged that is still waiting to be committed. The git status command is a simple, but important command, because it shows us the state of our project at this particular point in time. Now this is a git command that we'll be using quite frequently moving forward.

3. The third section lists the files that has been changed and staged for commit

These are the changes that will be registered in the git history if the commit command is used.

4. The fourth section lists the files that has been changed and not staged for commit

These are the changes that git has not been instructed to track.

Conclusion

You should use the git status command to check which files have been staged for commit and selectively proceed only with files that you want to be tracked by Git. For instance, in the example we demonstrated, the file db.sqlite contains the data associated with the project which is usually of a large size and not of much significance during development of the core features. In this case, the db.sqlite file should not be staged for commit in the remote repository. There are other git commands that take care of such scenario which we have taken a deep look in associated articles.

Happy Git Learning!