First off, why would you want to do this? Well, sometimes when you’re working on a project with other people (or even just yourself), it can be helpful to know what files are modified and which ones aren’t. This way, if someone else has made changes that conflict with your own work, you can merge them together or figure out how to resolve any conflicts before pushing your code up to the main branch.
So let’s say we have a simple project called “my-project” and we want to check for any uncommitted changes using Git status. Here are three different ways to do this:
1) The traditional way (using `git status`) This is what most people use, but it can be a bit confusing if you’re new to Git or don’t remember all the commands off by heart.
#!/bin/bash
# This is a bash script to check for uncommitted changes using Git status.
# Navigate to the project directory
cd my-project
# Use the traditional way of checking for uncommitted changes
git status
# Output the current branch and its status
# This is to provide context for the user
echo "On branch $(git branch | grep \* | cut -d ' ' -f2)"
# Check if the local branch has diverged from the remote branch
# If so, prompt the user to merge the changes
if [ $(git rev-list --count HEAD..origin/master) -gt 0 ]; then
echo "Your branch and 'origin/master' have diverged,"
echo "and have $(git rev-list --count HEAD) and $(git rev-list --count origin/master) different commits each, respectively."
echo "(use 'git pull' to merge the remote changes into yours)"
fi
# Check if there are any uncommitted changes
# If not, inform the user that the working directory is clean
if [ -z "$(git status --porcelain)" ]; then
echo "nothing to commit, working directory clean"
fi
In this example, we see that our current branch (which is called `master`) has diverged from the main branch on GitHub (called `origin/master`). This means there are two different commits in each location. However, since we’re currently on a clean working directory (meaning no changes have been made), there’s nothing to commit yet.
2) The fancy way (using `git diff`) If you want more detailed information about what files have changed and how they differ from the original version, this is the tool for you! It can be a bit overwhelming at first, but once you get used to it, it’s pretty handy.
bash
# This script uses the `git diff` command to show changes made to a file since the last commit.
# The `-git diff` command compares the current version of a file to the previous version.
# The `a/README.md` and `b/README.md` refer to the original and modified versions of the file, respectively.
# The `index ea2c51..d3f67e 100644` line shows the index of the changes made.
# The `--- a/README.md` and `+++ b/README.md` lines indicate the start of the changes in the original and modified versions, respectively.
# The `@@ -1,8 +1,9 @@` line shows the line numbers where the changes occur.
# The `-1,8` refers to the original version and `+1,9` refers to the modified version.
# The `1` indicates the starting line number and `8` and `9` indicate the number of lines changed.
# The `# My Project` line is the title of the project.
# The `- This is my first commit!` line indicates that this is the first commit made to the project.
# The `+ This is my second commit!` line indicates that this is the second commit made to the project.
# The `+ Here's some new information:` line indicates that new information has been added to the project.
# The `* Added support for Windows users` line indicates a new feature added to the project.
# The `* Fixed a bug with the login page` line indicates a bug that was fixed in the project.
In this example, we see that there have been changes made to the `README.md` file in our working directory (which is represented by “b” in Git’s notation). Specifically, two lines were added and one line was changed.
3) The lazy way (using `git log`) If you just want a quick overview of what changes have been made recently without getting bogged down in details, this tool can be pretty useful! It shows you the commit history for your current branch, which can help you keep track of who did what and when.
#!/bin/bash
# This script uses the `git log` command to show the commit history for the current branch.
# The `-n` flag specifies the number of commits to display, in this case 10.
git log -n 10
# The `commit` keyword indicates the start of a new commit entry.
# The long string of characters following it is the unique identifier for that commit.
# The `HEAD` and `master` keywords indicate the current branch and its name, respectively.
commit d3f67e5c2a4d89123456789abcdef (HEAD -> master)
# The `Author` keyword is followed by the name and email of the person who made the commit.
Author: John Doe <[email protected]>
# The `Date` keyword is followed by the date and time the commit was made.
# The `-0700` indicates the time zone.
Date: Wed Apr 21 14:30:00 2021 -0700
# The `Added` keyword indicates that new functionality was added in this commit.
# In this case, support for Windows users was added.
# The `and` keyword indicates that multiple changes were made in this commit.
# The `fixed` keyword indicates that a bug was addressed in this commit.
# The `with` keyword indicates the specific bug that was fixed.
# The `login page` specifies which page the bug was on.
Added support for Windows users and fixed a bug with the login page
# The `origin/master` keyword indicates the remote branch that this commit was pushed to.
commit ea2c51d6e8f7abcdef (origin/master)
# The `Author` and `Date` keywords have the same meaning as before.
Author: Jane Doe <[email protected]>
Date: Tue Apr 20 13:00:00 2021 -0700
# The `This is my first commit!` is a message left by the author of the commit.
# It can be used to provide a brief description of the changes made in the commit.
This is my first commit!
In this example, we see that the most recent commit was made by John Doe and it added support for Windows users and fixed a bug with the login page. The previous commit (which is represented by “origin/master”) was made by Jane Doe and it just contained some initial text in the README file.
Which one do you prefer? Let us know in the comments below!