Different Royal Breakfasts (Meet Git #7)
How to check what has been committed and when
Introduction
A change is something that drives the progress of everything. Without changes, we would stick to a plain sandwich, but now we’ve got a quite decent breakfast.
Because changes are so important, today we’re going to take a look at how The Royal Breakfast was evolving in time. To achieve this, we’ll use git log
, git diff
and git show
.
Show what has been committed and when
Check details of the particular commit
To recall, we’ve got three commits in our history, and say, we would like to check details of the first commit (1033ca3
).
To get more information about that commit, type git log 1033ca3
, or even shorter git log 1033
, provided you can uniquely identify the commit. If you want to display all commits, just use git log
, without specifying the commit’s checksum.
As you can see, this doesn’t present the exact changes in the recipe, though. To find out what changes have been introduced by commit 1033ca3
, use git show 1033ca3
.
Apart from metadata, such as an author and commit date, you can see the all changes made within the royal_breakfast.txt
recipe.
In general, git show <commit_sha>
gives you details on what has been changed in a particular commit, compared to its parent. The first commit in Git repository is a bit special, though, because it has no parent commit!
How to know which commit is a parent of another? To get a nice view of history in your repository, and to see relationships between commits, I encourage you to create the git lga
alias in Git. I have described the required steps here¹.
Check differences between two versions of the breakfast
If you would like to know, what differences are between a broader set of commits, use git diff from_revision..to_revision
, for example, git diff 1033..cab78
. In this particular example, Git will display changes introduced by c033
and cab78
.
Show differences before you commit next changes
The well known git diff
command lets you not only review the history of already committed snapshots, but also helps you find out
- what has been changed since the last commit (e.g. if you modified the recipe with your favorite text editor)
- what is to be committed (when you modified the recipe, and you’ve already staged changes, but haven’t committed them yet)
What has been changed since the last commit?
To figure it out, you can use two commands:
git status
tells you which files were modifiedgit diff
provides more detailed information and shows what exactly has been changed within tracked files
There is one important note regarding using git diff
. If you have a long line of text, and you’re changing only a few words within it, git diff may produce quite confusing output, like in the screenshot below.
At first glance, it looks like I changed a lot within royal_breakfast.txt
. In reality, I have changed only a single word. The output looks as it looks because by default git diff
detects whole lines that are modified. To get a better view of what I really changed, I used git diff --word-diff
, which highlights only words that were changed. The output of this command has been shown in the next screenshot.
What changes are going to be committed?
If you staged (prepared) changes for the next commit, git status should produce output as shown below.
What’s interesting, git diff
doesn’t show any changes. It’s because git diff
compares the working directory that is not staged. The royal_breakfast.txt
has been already staged, so use git diff --cached
instead.
Under certain circumstances, Git displays information that may look even more confusing. Namely, if you type git status
, Git can tell you that the same file is
- modified but not staged (marked in red)
- modified and staged (marked in green)
This simply means, that you had modified a file and staged it. Later on, you decided to introduce another changes in the same file, without adding the file to the staging area again.
If I type git diff --word-diff
, the output says I added “chop chop” in the text, and this change is not staged, because I used the command without the “cached” flag.
On the other hand, if I type git diff --cached --word-diff
, the produced output says that the word “Finely” has been replaced with “Roughly”.
If I committed the file as it is, my new commit would only contain the change from “Finely” to “Roughly”. Let’s see if my assumption is correct, then.
Next steps
Did I really want to roughly chop the onion? No, I didn’t. How to make breakfast royal again, then?
In the next article, I’m going to show you how to revert unwanted changes in a few ways, depending on the context.
Stay tuned!
References
[1] Krystian Szpiczakowski, The History of The Royal Breakfast (Meet Git #6) https://medium.com/codex/the-history-of-the-royal-breakfast-meet-git-6-b1a8a2b521ba