Inspect a Git repository — 14 days of Git
So far on my 14 days of Git learning journey I have dug into:
Now it’s time to start using Git and look at how to inspect a repository.
Inspecting a git repository
There are times when you will want to check the status of a repository on your local machine, or when you want to look back at the history.
Maybe you haven’t touched the repository for a few days and want to check what state you left it in.
Or maybe you have an issue and want to understand why and how to resolve it.
This is where the command git status can help.
Git status displays the state of the working directory and the staging area. It will show you any changes which have been staged, which haven’t and any files that Git is not tracking.
Git status won’t show you the commit history of the repository though.
I have a git repository on my local machine and when I type in git issue I get the following information back:
This tells me that there are files stages but they haven’t been committed yet.
If I commit the changes and then do git status again the information displayed back to me changes:
It’s now telling me there are changes on the local repository that should be pushed to the remote repository.
What about the commit history though? What if I want to see what changes I have already committed?
Git log is the command you want to use to see the repositories commit history.
You can get a lot of information back from this command. The space bar to help you scroll down and you can exit it using q.
If you want to make it a bit more manageable to read and if you are looking for a specific period of time you can use some addition syntax on the command to limit the information you get back:
The above command will only display the last three commits for you.
You might want to only see small bits of information about each commit. You can do that use the command:
What if you wanted to see what files were altered and how many lines were added or removed for each commit? Well you can do that with the following command:
Git blame is a useful command if you want to understand who authored a certain change in the history of the repository.
You can’t just use git blame across the repository you need to specify a specific file you want to query.
Note that it is case sensitive. If your file name is all in caps you need to use that within the git blame command.
We can trace here who the author of certain changes was, we can see the commit ID, date and the changes that we made.
14 days of Git
Today has been really interesting digging into more advance commands and understanding their usage. I look forward to putting this new found knowledge into more context over the next few days with other commands.
You can follow along here: https://github.com/weeyin83/14daysofgit
Originally published at https://www.techielass.com on September 21, 2022.