Today Icelab Learned
 about git

Restore a file with git checkout

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.

Pushing all branches

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

Creating and pushing a git tag

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.