I love jeweler for releasing my gems, however I tend to forget how it is working, so here’s my release workflow.

1. Bump and Commit

Bump the version (usually in lib/a_perfect_gem/version.rb) and git commit my latest changes

2. Doublecheck

git status to check if my working tree is clean

git status
# On branch master
nothing to commit (working directory clean)

Otherwise jeweler will complain

$ rake release
rake aborted!
Hey buddy, try committing them files first

3. Release

Finally do

$ rake release

which will

• tag the commit with "v#{A_PERFECT_GEM::VERSION}"
• push the commit(s) to origin
• push the tag to origin
• build the gem
• push the gem to gemcutter

Props to [technicalpickles].

Branching

If you’re planning to

• change huge parts of your code at once
• introduce a complex new feature or another API
• switch easily between different – simultaneously running – development processes of your project (actually, that’s called a branch)

you’re better off creating a new branch. As soon as you switch to this branch, the former version won’t get touched anymore. You can easily merge back the changes from the new branch to your master version.

First, list the local branches

git branch

Creating a branch
You start by creating a new local branch

git branch dynamic

we call the new branch dynamic.

Then switch to your new branch. The code will be the exact state when you left the former branch.

git checkout dynamic

You can now apply changes, commit and push to your new branch.

Don’t forget to push the new branch to your remote repository

git push origin dynamic

Merge the branch back
After you think your changes should go back to the master branch, merge ‘em, where the newer will supersede all of master

git checkout master
git pull . dynamic
git push

{is git pull . dynamic + git push =?= git merge dynamic}

Tagging

I often explain a tag in git as a bookmark which lets you return to some specific version of your code. As you can have an unlimited amount of tags, you can have as many bookmarks as you need.
So when you want to take a snapshot of your code saying “if I had releases, and would package my code, this version would be packaged as 2.2.1.tar.gz” why not simply tag it as 2.2.1?

To list the bookmarks you already made, enter

git tag -l

Creating a tag
Right after you found some nifty name for your tag – let’s say we call it 2.3 – create an annotated (not signed) tag with

git tag -a 2.3

Until here the tag will reside in your local repository only and will be pushed to your remote repos instantly if you command

git push --tags

You can switch back to any version you tagged using

git checkout 2.3

which is really helpful for both developers and users since you can distribute multiple versions in one repository.

Deleting a tag
If you simply want to delete a local tag, do

git tag -d v3.3.4

However, if you need to remove that tag from your remote github repository, you simply push nothing to the tag name.

git push origin :refs/tags/v3.3.4