Git and GitHub

XKCD shows us what not to do.

I kind of like this convention system for commit messages. Start commit message with one of these.

It is also recommended to style the commit messages with something like this.

Avoid stuff like this.

I think of it as answering the question, if this commit is applied, what will transpire? This first line is really the "subject" line of the commit message which is often all that is needed.

Andrey’s style is interesting too. He starts messages with a symbol.

That may be a more compact approach.

Many operations use merges behind the scenes. If the A is a direct ancestor of B, then merging B and A is a "fast-forward merge" where the label simply can be moved since B knows all about A because the topology simply points back to it.

Let’s say you’ve started a project and then you realize someone has a project that is similar to yours with a lot of stuff you like and you want their project to be incorporated into yours.

Later maybe the BigProjectTemplate folks have fixed some important things that you’ve pulled in. You might get a message like this.

You need to do git push to get your 9 commits up to GitHub. Checkout your local master branch, do git pull. This will pull the 15 commits that you’re behind. Switch back to your development branch, and do git merge master. Then you’ll want to do another git push to get the merged version into your GitHub branch.

This is also the same situation when you have a collaborator who doesn’t register with your project as an official collaborator but rather keeps their own repository. Here’s an example of coordinating a merge, basically the same as shown before.

It’s mostly as simple as taking your up-to-date repository and doing something like this.

Renaming a Github repository is more involved and requires admin privileges. Check the "settings" tab of the project.

What if your project is becoming more complicated and you want to push some things into subdirectories? Renaming also works for that just fine. Here I’m tracking a Python module where I started collecting so many examples using it that I wanted to separate them from the main module code.

Note that git mv actually does the moving in your file system too.

GitHub has a nasty habit of pumping personal email addresses into the wild web. There is a "privacy" email that you can use. While logged in go to /settings/emails and Keep my email address private and Block command line pushes that expose my email. Then for good measure you can configure your command line local user account’s git settings like this.

And check it like this.

Actually it can be a bit more involved now! If you get a message saying, push declined due to email privacy restrictions you can fix it following the advice described here. First find your magic Github "privacy" email address. This can be found here: https://github.com/settings/emails Then change to it in your CLI configuration. Mine looks something like this (but this is not exactly it!).

If you do that and try your push again it should now work out. Still, you pretty much should assume a complete breakdown of email privacy.

Go to your identity icon and then "Settings". Then choose "SSH and GPG keys". Then "New SSH key". When you paste the public key don’t worry about all the messy hard returns. It sensibly strips that all out. GitHub will then show you the md5 fingerprint if the key was successfully accepted. You can check locally if it matches with this.

(Looks like you don’t need to have the -E md5 option now. The default hash output seems to match better with what Github shows.)

Once GitHub has your SSH key you can test it. Note that the user to use is git, not your real GitHub username.

If everything goes very well, this may even load your SSH key’s password into an agent so you won’t have to worry about authentication again during this session.

It seems like to create a repository on GitHub, you have to use the web interface and do it from the web site. All subsequent operations can be done using the command line. While logged in look for the "+" sign in the top right menu. Click that and choose "New repository". Here I’m calling it "probe" (i.e. just a test); interestingly I do not have to call the working directory the same name.

That’s how you do it for using the web authentication credentials… But I wanted to use SSH keys. Make sure you select SSH and not HTTPS from the GitHub website after you make your repository there. Git rid of the incorrect "remote" named "origin".

Since the key is decrypted and loaded in the agent, it runs immediately with no more fuss.

You can create new files directly in the GitHub website. Or maybe someone else (or you from a different computer) committed some new stuff. Here’s how to update what’s in your local copy.

And if you want more control this is the explicit way to phrase the command.

Remember that origin is the (arbitrary but conventional) name of the remote and master is the branch to acquire. Basically push and pull move things from remotes to branches and vice versa.

A fork is just a clone that GitHub makes for you on their own servers. GitHub also keeps track of the number of people who have made forks of your repository. If you don’t want to keep tentacles of the original project, just clone it locally. Then create a new project on GitHub, set a new remote for that new project and push it. Not having to do this is what forking is all about (but sometimes maybe that’s how you do want to play it).

Here’s some terminology topology where A,B,C,D are commits.

On the project’s repository page, go to "Settings" (right side menu). Then "Collaborators" (left side menu). Add the GitHub username of other contributors and click "Add collaborator".

If local changes have been made and it is likely that remote changes from other collaborators have also been made, then safely update the local copy with a branch to a new origin/master leaving the local master alone.

So if you wanted to have access to all the changes that have been applied remotely without incorporating them immediately into your current commit use fetch. Note that these are equivalent.

Basically I’m asking some project owner to pull in my changes. Or something like that. Probably it would have been better named merge request. There are a lot of tools on the web interface for requesting this and approving it. I don’t know exactly what the story is on the command line, but it’s probably not critical to me right now.

To send a new branch to GitHub as a new branch.

Often when you’re mucking around with some code cloned from someone else, it’s important to change the "base fork:" property. In the "Open a pull request" page, find that selector and change it to something less meddlesome to the official project (unless you really want to request that the official project pull your changes into it).

When a pull request has been made on your project, assuming no problematic conflicts, you will be able to do one of the following.

Once you’ve done the merge and seen the "Pull request successfully merged and closed" message, you can delete the branch by clicking the button that encourages you to do so.

Sometimes you fork some project, clone it to your local system, make some changes, and push them back to your fork. But meanwhile, someone has made conflicting changes to the project you forked messing up your intentions of a pull request. You may need to clone not just your fork’s situation but also the new situation on the main project. Note I’m not calling it the "original" project because "origin" is a GitHub slang for the remote location used in push and pull. The name "upstream" is often given to the project you forked from. So to sort that out do something like this.

This will push an updated version of mynewstuff to your fork which will then stand a better chance of being accepted. Note you can’t send it directly to upstream since that is probably not yours. You can just send the "globally aware" version of your changes to your fork and that fork’s status should get updated to say, no conflicts.

Sometimes you’re just testing (or some researchers at your university are caught in a vicious turf war which turns some of your little programs into hotly contested "intellectual property" which you are no longer allowed to benefit the world by making public) and you need to just completely get rid of a repo. This kind of URL will take you to the settings page.

https://github.com/chrisxed/$MYREPONAME/settings

At the bottom of that you’ll see a red section called "Danger Zone". There you will find a button to ditch the whole mess. "This action CANNOT be undone. This will permanently delete the $MYREPONAME repository, wiki, issues, and comments, and remove all collaborator associations." You must type in the name of the repository to confirm.

And one of my least favorite things about GitHub — a complete and valid reason not to use it — is that if you accidentally check in some sensitive information, it can be damn difficult to feel confident that you have cleaned up the mess. I know that BTC pirates were crawling GitHub for AWS API keys and AWS had to start preemptively doing that too. I’ve never had that problem, but I have accidentally checked in source code that contained a personal email that I really didn’t want to make public. I just nuked the repo as described above and recreated. But there may be slighty better ways. They sure look bleak though.

It tuns out that if you’re doing a bunch of fancy stuff with a bunch of other fancy people and you’re all merrily using Microsoft GitHub you will almost certainly be forced to use GitHub’s horrendous web interface, for example to generate pull requests. But there may be a way around that problem. There is an official GitHub project called GitHub CLI that is intended to be a way to avoid the horrid web mess.