Month: January 2017
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
head:<branch-name>
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.
Suppose you want to restore a branch that’s been deleted after you merged a Pull Request. (TBH: I’m not sure under what conditions you want to restore a branch that’s been merged. If you need to make more changes, my guess would be to create a new branch and a new Pull Request. I’m curious to hear other’s thoughts in the comments.)
But when you go to your list of branches by clicking the Branches link above the repository language bar
You’ll find that your recently deleted branch (e.g. readme-draft) isn’t listed.
Since the readme-draft branch you saw me delete from the previous tips is tied to a Pull Request, you can navigate back to that Pull Request (make sure you search for closed Pull Requests!!)
and now you’ll see the button to restore the deleted branch.
Clicking on Restore branch button takes you right back to where you were at in the Pull Request before you deleted the branch, with the exception of history that you’ve restored the branch.
You’ll also see the branch come back in the Branch:master dropdown switch button.
