Tag: repos

How to view a diff for a commit as files side by side on GitHub – 028

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.

How to view the diffs for a specific commit for a specific branch in GitHub – 027

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.

How to view all files in a repo for a given commit on a given branch on GitHub.com – 026

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.

How to merge your own pull request on a branch you created on your own repo – 022

Today’s tip completes the workflow started in Tip 019 – How to create a pull request for existing branch in your own repo. The scenario is you have a readme you’ve created on a branch and it’s ready to be merged. Even though you are the only contributor to the repo, you still have to use a Pull Request to merge, if you are using GitHub.com to handle the merge instead of command line.

Remember, a pull request is the start of a conversation, even if you are the only developer on the repo. Reviewing your own Pull Requests is kinda like practicing conversational French by yourself. Nothing wrong with practicing your vocalization, but a Pull Request was designed to get points of view from other people. Consider the following true-story exchange:

Host family: “Est-ce que tu veux dîner?” (Want to go to dinner?)

Me: “Non, J’ai faim,” as I shake my head no saying “I’m hungry”

Host family:

In yesterday’s tip we saw that master (the base branch) has 13 commits (at the time of this blogging),

but readme-draft branch (the target branch) has 16 commits.

Using my random-example repo, you’ll watch me merge Updated the readme (PR #1) into the master branch in the steps below.

Two things to note

There are no conflicts with the base branch (aka master) because we’re adding a new file that doesn’t currently exist in master
There are options to how we could merge this pull request (the dropdown arrow in Merge pull request), but you’ll read more about these in upcoming tips.

Clicking on Merge pull request presents you with a form to fill out

“What?? Another form?? Didn’t I already fill out a form when I created the Pull Request???”

My thoughts exactly Smile When you created a Pull Request, you filled out a form to start a conversation. This form is documenting the merge. These comments will live in the Git log, whereas the Pull Request title and comments live on GitHub.com.

In the scenario where you are making a code contribution to someone else’s repo (i.e. a repo you don’t have commit access to), you wouldn’t see these options to do the merge. But in the case where you want to merge branches in your own repo, you are documenting that you approve and merge your own code, aka you’re merely having a conversation with yourself! Smile

Use the default comments and click confirm merge and you should see the following message:

Going back to the repo homepage, you know see that master has gone from 13 commits to 17 commits (13 original commits + 3 commits from readme-draft + 1 commit for the merge = 17 commits)

I’m covering the easiest scenarios right now to get warmed up, and also, because I’ve never tried playing with the other Merge pull request dropdown options yet. But that’s why I’m doing this series… to force myself to learn!