Similar to `git checkout <branchname>` you can do something similar on a repo using the GitHub UI.
I’m an extremely visual person. For me to understand a concept, I have to physically see it, even if it is just a drawing representing the concept. For a long time, I thought a branch in Git would only contain the diffs. Seeing a branch represented on GitHub.com helped me appreciate what Git is doing.
Using my random-example repo, I have 2 branches which you can see from the repo bar. In this demo, my master branch does not have a README.md file, but my readme-draft branch contains the README.md file. (Let’s say I used the GitHub.com UI to create the README.md file and committed the file to a readme-draft branch, as seen in previous tips).
You can “switch branches” by clicking the Branch: master button located the top of the repo list of files, and then selecting the name of the desired branch, e.g. readme-draft in the example below.
Now when you switch to the readme-draft branch, you’ll see the dropdown button change to indicate the new branch.
A few callouts:
- The branch button has changed from master to readme-draft
- GitHub tells you where this branch is in respect to the default branch. Note I say default branch and not master branch… more on this in future tips (but know the master is the default when you create a new repository.)
- Not only do you see all the same files from before on master, you also see the new README.md. Welcome to the world of Git!
This is when it clicked in my brain that a branch contains a snapshot of whatever it was based off of when created (in this case, readme-draft was created based off of the master branch) and then any modifications made to it (i.e. I added a new README.md file to the readme-draft branch).
One of the biggest concepts I had to learn when using GitHub.com the first time is that the much of the repository metadata comes from content within the repo files themselves. To illustrate, back in the day on CodePlex, your license and homepage content were stored as part of the CodePlex project, instead of being generated based on the contents of your repository. Once I made this mental switch, GitHub got a lot easier to use. And FWIW, as I learned in UX grad school, it’s much, much easier to learn a new skill than it is to unlearn an old skill to learn new similar skill.
And what I mean by the title of this post is the content that appears at the bottom of the list of files in your repo. E.g. the electron/electron-api-demos shows a few lines of text and then an image, and then the rest of the readme file.
And yes this is a possible duplicate of #003, but if you don’t know this content is coming from a README.md file, you won’t know you need to add a README file. I felt it important to include these points of view.
Let’s say that you did not check the Initialize this repository with a README checkbox when you first created your repository.
You’ll won’t see the default generated README.md content (which is just the name of your repo and the description, if you provided one).
These days, you’ll see a nice information box encouraging you to create a README.
If you click this button, you’ll be taken to the familiar “Create a new file” UI on GitHub, where it creates a new README.md file. If you use all the provided defaults, you’ll get the same generated README file as if you had checked the Initialize this repository with a README button on the new repository page.
Suppose you have a file that you want to delete*, but don’t want to break out a command line interface to do so. You can delete the file directly from GitHub.com.
Next you can commit the changes to delete the file to the commit.
*Note that this Delete this file button only removes the file from this commit on this particular branch moving forward. It won’t delete the file in any previous commit history or other branches (until they are merged and only from this commit moving forward).
If you need to permanently delete a file (or even if don’t, you still need to read this doc if you haven’t already), check out GitHub’s documentation on Removing Sensitive Data.
Why no -r delete option (read: why no recursive delete)? The shortest answer is this is how Git works as a Distributed Version Control System. If one or more people have cloned your repo, and if anyone changes their Git repo history, the repos won’t be compatible anymore (there might still be a way but it’s way beyond my skills as of today). And note how I’m saying this is how Git works (instead of “how GitHub works”). This is Git functionality. If you want to read more for possible options, check out the git-scm documentation on rewriting history.
You don’t have to use the command line to create a branch. You can also create a branch directly on GitHub.com. And even though the Create a Pull Request page appears, you can cancel out of it.
Suppose you want to make changes to a readme, but you know you want to make a few iterations on the file before it is final. Or perhaps you want to preview the readme as it will appear to visitors of your repo before it goes “live” on the master (default) branch. Using branches is a great way to store your changes online (where others can still see) that’s separate from the master branch.
First, you’ll click the README.md file in the repo file list.
Second, you’ll click the Edit this file button on the far right of the file.
Next, you’ll make your changes. For my example, I’ll add some content and a link back to MSDN Documentation. (Don’t forget to Preview Changes!)
Lastly, instead of using the defaults to commit directly to the master branch, you can specify to Create a new branch for this commit and then click Propose file change.
Note in the image above I created a branch called readme-draft, but any branch name will do, including the default name generated (not shown, but it is usually username-patch-1).
The next screen to Open a pull request might feel like it is required, but it is optional. Your branch has already been created.
Simply click on Code tab or anywhere else to leave this page. You can always go back and create a pull request later, which we’ll cover.
To view all the keyboard shortcuts on GitHub, simply press the question mark key on any GitHub.com page and you’ll see the following image:
Pressing question mark key on any page will show you the shortcuts available, whether they are global (for any page) or for a particular page (e.g. Issues).
And as you’ve figured out by now, the Show All link will show all shortcuts, regardless whether they will work for the page you are currently on, hence why there’s so much whitespace in the image above.
I wanted to share this tip now, so you don’t have to wait for me to discover your favorite shortcut. I’ll go over these more over the upcoming months
You may not have noticed before, but each GitHub repo page has a Find file button next to the Clone or download button. It’s amazing how many times I’ve clicked the clone button and never even noticed this Find file button.
The File file button takes you to the File Finder page. For example, in the image below, you’re seeing the files from my UX Masters project TheoryC.
And from this screen, you can start typing the name of a file.
But why click a button when you can use a keyboard shortcut?!
GitHub has a great collection of keyboard shortcuts. I’m ramping up on these shortcuts myself, hence this blog series. Let’s start with finding files.
On a repo home page, for example https://github.com/saraford/TheoryC, you can press the letter t to navigate directly to this File Finder page.
Now type the name of the file or folder. e.g. I want to go to the MainViewModel class. So I can just start typing “main”.
Notice how in the previous image all I had to type was “main” and the file finder found three files using partial matching. I didn’t have to specify which folder these files resided in. The search was exhaustive throughout the repo.
To recap, to search for a file via the keyboard, press the letter ‘t’ and then start typing the name of your file. No button clicks required
For those non-Windows users wondering “What the…This is supposed to be a Git(Hub) Tip of the Day!!” I promise it is. But remember, this is a Windows-first, non-Windows friendly blog series, so from time to time you’ll see some tips that only Windows users can relate to. Think about it this way. If you ever need to use Windows in the future, it can’t hurt to have a few tricks up your sleeve 😉
A coworker was telling me how much he missed the old Windows 7 Start Menu experience, where pressing the Windows Key immediately opens the Run dialog. I’m including this tip here in the series because if you are a Windows user and do not know about this yet, this tip will change your life on Windows.
Press your Windows Key and your Start Menu appears.
Note in the following screenshot:
- I manually removed all of the live tiles. There’s an option to hide if you right-click on each live tile.
- I’ve had the Windows taskbar docked to the right side of my screen since 2005. You’re able to see more items listed and you can read more of each item name, which is especially useful if you have multi-instance apps. E.g. if I had two instances of Open Live Writer open, I’d know which blog post I’m editing. But I digress…
Now for the moment you’ve all been waiting for, take the leap of faith and just start typing, e.g. “notepad”
You’ll see below that the Windows start page thingy changes to the old school run dialog (of sorts). You’ll see whatever you type is shown at the bottom.
Be aware that if you mistype a word, like “notefoo”, Windows will kick off a Bing search in Edge for “notefoo.” There’s probably a way to customize this, but just be aware of some interesting Bing results from your typos!