Month: January 2017

How to restore a deleted branch that is associated with a Pull Request in your repo – 024

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.

How to tidy up after merging a Pull Request in your own repo – 023

Following yesterday’s tip, after a Pull Request has been merge, you’ll see a message suggesting that you delete the target branch.

But why would I want to delete this readme-draft? What data do I lose if I delete it?

First, let’s talk about this possible data. The data around the conversation was captured as part of the Pull Request, which was only closed (not deleted), so you can still find it on GitHub.

Second, the data around the commits was merged into master, so that’s not being lost. Stay tuned to the end of this blog post to see a screenshot of these commits sticking around after I delete the branch.

Third, you most likely won’t need to use this branch again. Over time, as your number of merges increases, you’ll have a long list of branches.

Hence it is considered good practice to clean up after your pull requests.

Fourth (and probably most importantly), this is a fundamental difference in how Git works compared to other source control systems. Branches are just pointers to a snapshot in time. More on this in upcoming tips when I start to play with Git command line concepts.

Lastly, you can always restore! Stay tuned to tomorrow’s tip.

Let’s delete this readme-draft branch. Click on the Delete branch button, and volia!

And you can look a few lines up and see that the Pull Request still contains all the commits, regardless that the branch was deleted.

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!

How to see a list of which commits a branch contains on GitHub – 021

I’m calling out this functionality now because after 2 years of using GitHub, today is the first time I’ve ever noticed this button on this page! And it’s sitting right in front of me!! O_O

At the time of this writing, my readme-draft is 3 commits ahead of master.

But suppose you want to see which commits these are.

First, switch back to the master branch (just to get the commit ID of the last commit there that readme-draft was based on, since I haven’t updated master since.)

In my example, my master branch only has 13 commits. Click on this Commits link directly above the language bar.

Now you’re looking at all the commits for this master branch. Note the last commit on master is “Delete README.md”

Now at the top of the page, you’ll notice the button I’ve failed to see for the past 2 years.

Click on the Branch: master dropdown button to switch to the readme-draft branch.

Now you see the list of commits in the readme-draft branch.

Note that the last commit shown in the image is Delete README.md, which is the last commit on the master branch. Listed above are 3 additional commits in the readme-draft branch, as the first image of this blog post said there were 3 commits ahead of master.

You could (and should) compare commit IDs, listed on the far right of each commit, since the commit message could be the same for different commits. But for this trivial example, I’m only showing the titles of the commits.

How to add changes to a Pull Request after you have already created a Pull Request – 020

If I could go back in time, this is one of the first tips I’d tell myself about using GitHub. Don’t think of a Pull Request as the final submission. Think of a Pull Request as the beginning of a conversation about the code you want to merge. It’s difficult to appreciate how a Pull Request is the start of a conversation if you are the only developer on a project, so you’ll see more tips on using PRs with other users later in the year.

At first, creating a Pull Request feels like you’re submitting a homework assignment. You might think that once you turn it in, that’s it. But that’s actually not the case with a Pull Request!

You can still go back and make edits to your Pull Request by making commits to its branch.

From yesterday’s tip, you followed along how to create a README.md file in a new readme-draft branch, and create a Pull Request to merge it into master. But let’s say you want to add more content to your README.md.

First, you’ll want to switch to the readme-draft branch using the Branch:master dropdown button.

In the readme-draft branch, you can click on README.md file and then the Edit this file button on the far right.

In my random-example repo, I’ll add the following sentences to the README.

I’ve switched to real-world sample code because I feel it is easier to grasp Git-related concepts when actual code is being used, rather than using “Hello from File1” or my joke examples. I learned in UX grad school that the more applicable the new information is made, the easier it will be to learn new concepts. You need to have “a hook to hang your hat on,” as the professor would say. E.g. I didn’t find out that cognition means the study of how the brain works, until I was in the 2nd week of class (which was a class called “Cognition”). I was completely lost; whereas all the psychology majors around me were learning the course material faster than Neo learning Kung Fu. My classmates already had a hook to hang their hats on, whereas I was learning that people study this stuff without going to med school.

Now commit these changes to the readme-draft branch (not a different branch).

So what’s happened?

Let’s pretend we never created a Pull Request. If you go to the readme-draft branch, you see your changes, just as you’d expect from previous tips.

But we already created that Pull Request, so let’s take a peek at it.

Go to the Pull Requests tab, and click on Updated the readme to view the Pull Request.

The item circled is the commit we just did. Remember, this list above is of commits and not the files that were modified. I can’t recall how many times I’ve had to silently remind myself this.

How to create a Pull Request for an existing branch in your own repo in GitHub – 019

Yep, if you’ve been reading this series, you knew this tip was coming.

For explanation purposes, I’m going to ignore for now the Compare & pull request buttons you’ve probably been seeing if you’ve been following along at home. Why? Because I find it more straightforward to explain how things work when you have to set it up manually the first few times. Otherwise, it’s just magic happening under the scenes.

The scenario is you’ve created a README.md file in a branch called readme-draft on your repo. You created the README.md file in this non-master branch, because you wanted a few days to work (and sleep) on your writing. Now that you are ready to commit the file, you want to merge it into master. Let’s also assume (for now) you are like me, a solo developer on many of your repos.

(aside: I’m pretty sure the only way to do a merge on GitHub is via a Pull Request, even if you are the only developer. Here’s the corresponding SO question/answer to sanity check.)

First, you’ll click on Pull requests tab. (It doesn’t matter which branch you are currently viewing.) Then click on the New pull request button.

Next you’ll need to specify that you want the readme-draft branch (head) to be merged into the master branch (base).

(If you tried the other way, you’ll immediately get a message that “readme-draft is up to date with all commits from master,” because remember, the readme-draft was based from master only 2 commits ago.)

Alrighty, lots happening on this page, but let’s chill, and only pay attention to 3 things, plus some lagniappe.

On this comparing change page, you’ll see the following items:

Able to merge. These branches can be automatically merged – Awesome. This means no merge conflict, so we’re good. We’ll cover merge conflicts later. It’s only mid-January
Create pull request – This is the action you’ll take next.
2 commits – something that took a bit of getting used to for me is that this is the number of commits included in this branch, and not the number of files.
Guides – using pull requests – there’s a little help button sitting off to the far side taking you to the about pull requests guide.

Press the Create pull request button and the Open a pull request form appears.

“What? Another commit form????” Well, that was my first thought creating my first Pull Request (or PR as I might sometime refer to it as).

My second thought was, “why doesn’t GitHub just use my last commit?” But recall, your last commit is just that… your last commit to a branch. It might say “fix typo” whereas the other 5 commits might talk about all the changes and updates you made to that branch. So you need a new form to represent all your work on that branch.

My third thought was “okay, on closer look, this isn’t the standard commit form after all. So… where does this title and description go?” Glad I asked. This title “Updated the readme” and description “In this pull request…” will be shown as an item on the Pull Request page for the repo (the page when you click on the Pull Request tab.) Think of this as the overall description for your branch.

Without further ado, click Create pull request.

And there you go! Your first pull request!

The Pull Request has been created. Note this does not mean your code has been merged. This just means your branch as been marked as wanting to be merged, in case there are other contributors on your repo that want to give you feedback. Your code will be merged once you click the Merge pull request button, but we’ll stop here for today. We’ll cover everything on this page in future tips.

Instead of providing end-to-end walkthroughs, my goal is to provide the smallest, yet practical, bites of information to chew on for 24 hours at a time. This is my personal spin on how to best deep dive into things.

How to make a commit to a non-default branch using GitHub – 018

Suppose you have multiple branches, and you want to make a commit to a branch that isn’t the default branch (which is almost always master, unless a repo maintainer changed it).

In my random-example repo, I added a README.md file to a readme-draft branch. Suppose you have a similar README.md file in a non-master (or non-default) branch in your repo and you want to update it via the GitHub UI.

First you want to switch to the readme-draft branch by clicking the Branch: master dropdown button.

Second, you’ll want to edit the README.md file. See previous tips for end-to-end walkthrough. In my example, I added a link to the MSDN documentation where I got the sample code.

Next, to save your edits to the README.md file, you can either commit to the readme-draft branch or create a new branch based on the readme-draft branch.

Now if this seems a bit different, it should! Before we were committing to the master branch. This time we’re on a different branch than master, and we could create a new branch (`readme-draft-draft` or `whatever-1`) based off of this current branch (readme-draft).

Again, this is one of those things about Git you have to get comfortable with. Creating a branch is a lightweight process because of how Git works (more on that later, probably late Feb or early March).

For this example, let’s keep it simple. You can commit directly to the current branch, i.e. readme-draft, by clicking the Commit changes button.

Now if you click Code (or go to the repo homepage), you’ll see the following changes:

A few things to notice in the previous screenshot:

You are still viewing the readme-draft branch.
This branch is two commits ahead (1. the creation of the readme.md file – done prior to this tip, and 2. adding the hyperlink to the readme in this commit)
The text `System.Random() from MSDN Documentation` is now blue, indicating the committed hyperlink change