9GitHub

This is a more methodical view of working within the GitHub environment; we’ve looked at some aspects of this in the previous sections, but not in as much detail.

The basic view of the project (repository) contents is that of Figure 9.3 and below:

Figure 9.4   GitHub—Repository contents

This view shows the contents of the repository for the currently selected branch, in this case the master branch (this can be seen in the branch button point 1 above).

This view just shows the root folder and its contents, files are given the symbol and folders the symbol . The most recent commit comment associated with the file or folder is displayed in the centre of the area and the time of its last modification displayed on the far right (in relative time).

This is similar to a Windows Explorer view, if you click the 11-resources link, it will drill down into that folder:

Figure 9.5   GitHub—opening a sub-directory

Once you have drilled down to a sub-directory, the link back to the root level is available by clicking the lab-01-website link next to the branch button (highlighted in Figure 9.5).

As you drill down further, the parent folders become clickable links in their own right in the same area.

It is also possible to go up a directory level by clicking the two full stops (..) that are listed as the first line of the content area (always just below the pale blue head bar) .

• As you click down through the directories, the latest commit changes to reflect the latest commit in that directory, in Figure 9.4 (root) the latest commit is [da038e3]; in Figure 9.5 (11-resources folder) this changes to [f52a6a5].

Go back to the root level of the project (Figure 9.4); now click the find file button, point 2 above (an alternative is to press the T key, this does the same).

Figure 9.6   GitHub—file view mode

This shows a list of all the files (along with the path) within the repository.

The cursor is by default positioned after the lab-01-website / (at the top), if you start typing something it will filter the list by that search (type 0, and you will have all the files and folders that start with a zero). Just press esc to return back to the normal view.

The file view can be useful, it saves you having to drill down through multiple folders (with a page load each time) and it means you don’t have to know which folder a file is in. It does however, become a bit cumbersome if you have a lot of files.

Viewing the contents of a file is easy; just click its name in either the content area or the file view and it will load the file in a viewer.

To view style.css, either drill down to it 11-resources/01-css/style.css or find it in file view and just click its name.

This will open a view of the file contents; it will look like Figure 9.7.

Figure 9.7   GitHub—viewing the contents of a file

The view shows all the lines in the CSS file, these are semantically coloured (see § 9.2.3).

There are also three buttons and three icons at the top of the file contents area:

Figure 9.8   GitHub—file view controls

The three buttons are used to examine different views of the file. The icons do things to the file. I look at each in turn.

The raw button 1 shows a view of the file contents without any formatting. It looks like this:

Figure 9.9   GitHub—file raw view

I’m not entirely sure what this is for, but it’s there if you need it.

The history button 3 shows all the commits associated with the file (this is analogous to the file history in Brackets, § 6.4.1).

Figure 9.10   GitHub—file history view

This is a commit view and I discuss how this works in § 9.4 where I talk about commits. You get the idea; it’s a list of all the commits that affected the file.

This is blame as in whose fault is it? It’s button 2, and it gives a more detailed version of the file history; it shows how the contents of the file have changed. Here it is:

Figure 9.11   GitHub—file blame view

This is a listing of the file contents and its showing that lines 1 to 29 are all associated with the first commit (D01 commit), lines 31 to 43 are the same. Line 30 however is listed as an incremental build. This is from when we were changing files to generate conflicts.

Clicking the icon will move the view of the file back to that commit (it shows the version of the file at the time of that commit), it will show the commits associated with each line of the file at that time. It allows changes to be viewed in turn all the way back to the first commit of the file.

The colour of the central vertical bar gives some indication of how recent the file was modified (newest yellow, oldest dark red).

I get the idea; it makes it possible to view every change to any file through the commit history. In practice, I’ve never used it.

This is the github desktop icon ( ), point 4 on the list.

GitHub has a desktop application (a GUI frontend for Git and GitHub). I don’t use it, I use Brackets instead. I can offer no opinion on it, I haven’t tried it—from the reviews I’ve read, it has certain restrictions (I don’t know what these are); but then again so does Brackets.

The final two icons edit ( ) and delete ( ) points 5 and 6 respectively allow the file to be edited (as we did in § 8.4) or (not surprisingly) will delete the file.

Both these actions require a commit to be made in the remote repository and I cover them fully in the next section (§ 9.3).

The file we looked at in the previous section was a CSS file, essentially this is a text file and it was displayed as such in Figure 9.7. GitHub knows it’s a CSS file and is able to colour it semantically^†1 to make it easier to read. It does this for all the common web languages HTML, JavaScript, jQuery &c.

Let’s view a different type of file, open the README.md file:

Figure 9.12   GitHub—file preview

GitHub doesn’t show the source code behind the file, it interprets it and renders it according to the rules of the mark-up language.

Similarly, if you open an image GitHub renders the image for you to see, here is logo.png:

Figure 9.13   GitHub—image file view

GitHub tries to do the right thing when you view any file in the repository.

†1		Symantec colouring or highlighting is the technique of colouring elements of the source code to reflect the category of the item, in CSS this might be rules, declarations, class names, element names units and arguments—they are all coloured differently to make the code more readable.