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.
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!
In the previous examples, you saw how to create a new file in the root directory. But suppose you wanted to create a new file in a new directory.
Follow the same steps as before by clicking the Create New File button. Then in the Name your file… edit box, type your folder name, and then hit a forward slash (the / since it leans forward) .
If you need to rename the new folder, press backspace until you backspace over the forward slash. Then you can retype the name of the folder.
Sometimes when I’m typing in an edit box, I’ll continue to hit backspace even though there’s nothing left to delete. I like that squeaky-clean feeling I’ve deleted it all. But if you’re like me and you’re thinking the cursor will just blink at you at the beginning of the file name edit box, yeah, you’re going to be in for a bit of a surprise. As I mentioned above, hitting backspace at the beginning of the file name edit box will deleted the forward slash, so you’ll now be editing the folder.
A 3-legged dog walks into a bar and says, “I’m looking for the man who shot my paw!” It’s one of my favorites.
And yes, I’ve started experimenting with animated gifs. Where was Snagit back in 2008 when I did the VS Tips? Oh yeah, that’s right. It sat unused because I refused to give up my MSPaint keyboard shortcuts. Hopefully I’ll strike the right balance with animation on the page without too much motion!
Sometimes I’ll create a new file, but the Preview doesn’t render the markdown and shows everything in plain text instead. And I’m left scratching my head :confused:
If you find yourself in this situation, look at the file extension for your new file (or lack thereof).
Simply add a `.md` to your filename, and now your Preview will work!
BTW if you get a “can’t edit” icon when you try to add the `.md` to the filename,
this is is because you are still in Preview mode. Click on the Edit new file tab to the left of the Preview and you’ll be able to edit the filename.
And Lenny Bruce is not afraid.