When you’re viewing changes to a markdown file, you have the option to compare the rendered versions in the diff view.
Let’s say you wanted to view the diff of my latest commit to my README.md in my random-example repo. By default you are looking at the raw markdown contents, i.e. the “source diff.”
But suppose you wanted to view the actual rendered markdown file as a diff. Click on the Display the Rich Diff button located in the upper right.
Now you’ll see the diff of the README.md file as a rendered file.
Something I had a hard time grasping early on using GitHub was why the latest commit would keep change. Obviously, at the root level (homepage level), the Latest commit is showing the latest commit for the entire repo, but why does it keep changing after that?
The latest commit is showing you the commit for the last time any files at this folder level were modified. Let’s look at my simple random-example.
When you go to the main repo page, you’ll see the Latest commit c8cac61 3 days ago (at the time of this writing) is the last commit to the repo.
But then if you click inside the Randomness folder, you’ll see the latest commit changes to Latest commit 567c29d 6 days ago.
And if you continue to drill down into these folders, you’ll see that the latest commit continues to change to c59c490 6 days ago.
What is with all these changes?
The latest commit is showing you the commit for the last time any files at this folder level were modified.
Again, I’m a visual learner (as you’ve noticed by now), so here’s an example. In the image below, you are looking at the C# Project folder called Randomness with Latest commit 567c29d 6 days ago. Notice how there are multiple files.
Clicking the Latest commit 567c29d 6 days ago shows the actual file(s) that were modified as part of that commit, which in this case was just one file.
Suppose you want to see the last commit made to a particular file because you want to know what changed. Using my Masters UX project TheoryC as an example (it’s a Kinect app to do experiments in Kinesiology where you follow a ball around in a circle), let’s say you want to see the last changes made to the ViewModel.
If you click on the ViewModels folder, you’ll see the MainViewModel.cs listed.
Now in the upper right, you can click on the commit ID shown, which is the last commit ID for the given file.
Clicking on this last commit shows the changes for that given commit.
P.S. Now you’re probably wondering, “Why on Earth would you need to modify your DataLogger or even your MainViewModel to make your DebugWindow moveable?” Yeah, great question. I have the hardest time saving just one functional unit of change per commit. Learning good commit practices is hard when you’re working alone, because it’s easier to let this stuff slide.
P.P.S. Since starting this series, I’ve learned through my research that you can actually add only certain files, one git add at a time, and commit just those! This solves my above dilemma. Stay tuned in mid-late February for how to do this!
Personally, I’m not a fan of the inline diffs that make you do homework to figure out what’s being added and what’s being removed.
For example, if you go to the Code – Commits page and click on the commit id for a given commit, as shown in the illustration below,
You’re taken to a page that shows the diffs as inline or unified for the file.
Fortunately, there’s a split button in the upper right hand corner that says Unified | Split.
Clicking on Split portion of the button will show the before and after changes side by side, which is just my personal preference.
Suppose you want to see what changed between two commits on a particular branch. First, you can go to the Code tab and change the desired branch (see previous tips on how to do this).
Next click Commits link,
and navigating to the desired commit, you can click on the commit id (as highlighted in the image below).
Now you can see all the changes for that particular commit.
I’m purely a visual person. I cannot put clothes into a dresser drawer. If it is out of sight; it’s out of mind. It’s that bad. Thus being able to view all the files in a repo for a given commit really helped drive home how Git is so different from other source control systems.
Going back to my random-example repo, suppose you want to see the state of the repo as of the first commit on master.
Navigate to the Code tab and make sure master is selected. (If you want to view the state of a repo for a commit on a different branch, use this Branch:master dropwdown button to change to desired branch.)
Now scroll all the way down to the original commit. You’ll see highlighted in the next image a <> button that displays a tooltip Browse the repository at this point in the history.
Clicking on this <> button takes you back to what looks exactly like the repo homepage, but with one key difference…
Instead of branch:master or branch:readme-draft, you’re now seeing this Tree:ad98b093 thingy.
What’s a tree? This question gets into the internals of Git, which we will learn together this year! To be honest, all I know right now is that every Git commit has a tree, so this dropdown button label is saying, “show me the files for this commit id.” You’ll also notice that
You’ll see that this Tree:ad98b093 commit id matches the id in the far right.
You might be wondering why the dropdown doesn’t show the list of all the possible trees to view. My guess is this list would be come unmanageable pretty quickly. And people probably don’t need to look up the state of a repo at a given snapshot very often.
In yesterday’s tip, it was easy to find the desired Pull Request when there’s only been one Pull Request created. Today, let’s say that you want to restore a deleted branch, but you need to search for the Pull Request to get to the Restore button. Deleted branches aren’t shown on the Branches page.
Navigate to the Pull Request tab, and in the search field, 1. delete the search defaults and 2. type in
Notice you’re using head: as the search parameter because there are two branches involved in a Pull Request. The base branch is the branch that the changes are going into. The head branch is the source of those changes.
And in the above screenshot, you see the Updated the readme PR that contains the readme-draft.
You can also search based on base branch using the base:<branch-name> search option. Check out the search documentation for more information.