Github.com for Command Line Users

Why would anyone who knows how to use git on command line care to use Github? Sometimes, it’s not worth cloning an entire project to make a simple change to a project when it’s hosted on Github. In such cases, the Github interface makes editing easy.

If you use git on a command line, but have never used Github online, Github.com might seem foreign. This might be the case even if you’ve used Github Desktop. You could go through the Hello World tutorial to learn how to use Github’s web interface, but it doesn’t spell out all of its functionality.

Probably the most important thing to note is that the buttons don’t exactly do what they say.

Clone ≠ git clone

The bright green button on the right side of a project repository’s main page — not to be confused with a Github Page — says “Clone or download”. But there is no local repository when using Github.com, so there is no replicating the remote repo onto your local drive. Rather, files are downloaded onto your computer not including the repository’s hidden identification data necessary for a proper clone. Even Github Desktop enables actual cloning and supports local repositories.

No staging

Github.com has an editing interface, which in essence copies files into a web cache as if the text editing box is a staging area. Files can also be downloaded and edited with a favorite editing program. When files are ready for commit, they are uploaded or their contents pasted into the web interface. No add necessary.

A pull request ≠ git pull

On the left side of the project page is a “New pull request” button. Normally, git pull runs a fetch and merge. But there is no git fetch, and there is no local branch to merge. Github should call this button “New merge request” since the function is calling for a merge of remote branches or same-branch file edits. Naturally, a merge would call for a comparison.

Compare = diff

It’s intuitive that compare is the same as git diff, but it’s not intuitive how to get to the function. To compare files, choose “New pull request”. There are three types of diffs that can be examined from this page:

• Branch — This default view shows buttons that initially appear as base: master and compare:master. Clicking on either of these allows users to choose different branches. Users can also compare files on branches’ timelines. For example, base: mybranch@{1day} vs compare: mybranch will show commits on mybranch from 24 hours ago through the latest, or commit marked HEAD.
• Fork; click on the link compare across forks to compare a project with a copy or fork of itself.
• Commit; click on the base: branch and compare: branch buttons and a box appears where commit numbers can be inserted. This allows users to compare commits of files on the same or different branches.

Two consecutive commits of a file can also be compared by clicking on the file’s History button.

Branching

With command line git, you can use git branch to create your own branches for your work and then commit and push only the branch you want. With Github.com, since there’s no local repository, there’s no local branching. Though one can simulate branching by simply copying and editing, these branches would have no markers or configurations to identify them.

Instead, branching is done on the Github repository, otherwise known as the remote repo. To create a new branch, create, upload, or edit a file; and then check the radio box under your commit message where it says “Create a new branch for this commit and start a pull request.”

Tracking

To track who made changes to files, click on a file’s Blame button.

Being a Contributor

You might not be able to push or merge your contributions if you’re not the owner of a project. Based on Github documentation, there is one Owner and there are Collaborators, or Contributors. Owners can protect branches and prevent other Collaborators from pushing changes to them. In such cases, a contribuor may only commit and make merge requests (poorly referred to as pull request). Github’s documentation is not perfectly clear on which functions are accessible by what type of user. A little digging through a project’s settings reveals that users can be designated as Administrators. However organized, accessibility of functions is generally set on the project’s Settings page via Branches and under “Protected branches”.

Buggy by design

One thing to be careful of is losing work between merges. It’s not exactly clear what happens, but Github seems to miss some changes in its diff function. This might have to do with the lack of identification of local files. Or maybe Github.com doesn’t automatically point HEAD to the latest commits, like when branches are merged. Whatever the reason, the Github.com user interface seems limited in its functionality. Because of this, beware.

The rest is self-explanatory

Hopefully, the rest is easy to figure out. For example, to use git init, click on the plus symbol on the upper right and choose “New repository”. Just remember that the web interface does not support the use of local repositories, and as a result a lot of git functions are not accessible through it.

For more about git check out this blog.