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.
Not only does the color bar show you a breakdown of language usage percentages, these labels are clickable!
In my random-example repo, if you click on the VB 16.5% (or whatever it might be by the time you read this), you’ll see
Now you can filter all files in repo based on language without needing text in the search bar.
If you ever want to quickly drag and drop files to a repo (perhaps you’re a speaker at a conference and want to share your slides for your sample code), you can use the Upload files button that’s on the far right of the repo page.
A wild drag and drop box appears! (sorry, that was a terrible pokemon go impression.)
Now you can drag and drop your files into the box. Note that as you drag files, you’ll see them queue up. (Could you technically call this queuing up in staging? Conceptually you could call it staging, but I doubt that’s what’s happening under the hood). Sorry, I digress…
and volia, there was much rejoicing!
Note you might say, “Wait a sec… how is this added but yet the repo bar is still a single solid green color?
Good catch! You might have to wait a minute or so and refresh. Today I had to wait a couple of seconds and then a couple of minutes. Check out the support page if you’re having any issues.
And remember, Linguist, the open source project that displays these language percentages, is accepting contributions!