Suppose you no longer see the message to Compare & pull request your recently pushed branches (as shown below), but you still want to create a Pull Request.
There are 2 other ways to create a Pull Request.
Option #1 – use the Branches list in your repo
You can go to the Branches listing in your repo,
and for the branch you wish to create a new pull request for, click on the
And now you’ll be shown the Open Pull Request form with the same defaults as before. Note again as yesterday, you’re taken to the base repo to open the pull request.
Option #2 – Manually create a Pull Request via the Pull Request tab
I like doing thing manually to truly appreciate what is happening behind the scenes.
First, in your forked repo (e.g. saraford-tips/your-moment-of-github-zen) go to the Pull Requests tab.
Then click on the New pull request button.
Yeah, I’m Captain Obvious here with that above screenshot! But notice what happens. You are again taken to the Open Pull Request page on the base repository.
If you like to write, you’ll often run into the text not auto-wrapping, especially on markdown documentation files.
Whenever you run into a case where the line isn’t wrapping, just look up and you’ll see the option to change the Line wrap mode from No wrap to Soft wrap.
Changing to Soft warp now shows the line wrapped.
I had to look up the difference between soft wrap and hard wrap, since I thought “why not just name it No wrap vs Wrap?” But I guess they wanted to be explicit in saying that this option wasn’t going to insert actual line breaks.
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!
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 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
Suppose you notice a typo in your repo description or you didn’t specify one at the time you created the repo. To the far right, you’ll see an edit button.
Clicking this button allows you to edit a description and a website URL.
Give it a little while, but your repo description will end up on the GitHub.com search page when you do.
I’m sitting here wondering, “is this a useful tip?” but then I remember that feeling I felt when I (finally) found how to do it. Originally I thought I had to update a repo file somewhere, since it took me a while to get used to what files GitHub’s UI gets it’s info from (e.g. license) and what files are metatdata for the GitHub repo itself.