If you commit and push a change to a file that you later discover you didn’t mean to make, you can restore a previous version of a file with git checkout

Let’s presume we have the following history:

*aacc272 - accidental change to foo.rb
*ac2eb0b - changes
*c688457 - bug fixes

We know that foo.rb is in the state we want in the commit with hash ac2eb0b. So we can run $ git checkout ac2eb0b path/to/foo.rb.

It’s worth noting that unlike passing a branch name to git checkout, this method is destructive and can discard changes in the working directory.

From the git man pages:

git checkout [-p|–patch] [] [–] …
When or –patch are given, git checkout does not switch branches. It updates the named paths in the working tree from the index file or from a named (most often a commit). In this case, the -b and –track options are meaningless and giving either of them results in an error. The argument can be used to specify a specific tree-ish (i.e. commit, tag or tree) to update the index for the given paths before updating the working tree.

Say you want to push up an existing repository to a new remote on your favourite repository hosting service. You can use the following command if you want to make sure you include all branches:

git push <REMOTE-NAME> --all

This is especially helpful when you want to immediately create some PRs!

To push all tags:

git push <REMOTE-NAME> --tags

If you’re releasing gems (or any other kinds of packages), git tags are a useful way to track those release milestones in the source code repo.

Creating a tag is easy:

git tag v1.0.0

So is pushing it to a remote:

git push origin v1.0.0

The Git Basics - Tagging section in the online git book is an easy-to-read overview of the various tag commands.