No excuse not to have your branching strategy taken care of, because: git-flow

First, get it installed. This takes less than a minute, at least on a *nix based machine. I’ve no idea what it takes on Windows, but hey, at least it’s available there too! I did a clean curl and install as shown. It took about 14 seconds solely because I wasn’t typing very fast today.

12:28 $ curl -L -O https://raw.github.com/nvie/gitflow/develop/contrib/gitflow-installer.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 2145 100 2145 0 0 1732 0 0:00:01 0:00:01 --:--:-- 1732
~
12:28 $ sudo bash gitflow-installer.sh
Password:
### gitflow no-make installer ###
Installing git-flow to /usr/local/bin
Cloning repo from GitHub to gitflow
Cloning into 'gitflow'...
remote: Counting objects: 1407, done.
remote: Total 1407 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1407/1407), 623.29 KiB | 428.00 KiB/s, done.
Resolving deltas: 100% (689/689), done.
Checking connectivity... done.
Updating submodules
Submodule 'shFlags' (git://github.com/nvie/shFlags.git) registered for path 'shFlags'
Cloning into 'shFlags'...
remote: Counting objects: 454, done.
remote: Total 454 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (454/454), 130.91 KiB | 0 bytes/s, done.
Resolving deltas: 100% (337/337), done.
Checking connectivity... done.
Submodule path 'shFlags': checked out '2fb06af13de884e9680f14a00c82e52a67c867f1'
install: gitflow/git-flow -> /usr/local/bin/git-flow
install: gitflow/git-flow-init -> /usr/local/bin/git-flow-init
install: gitflow/git-flow-feature -> /usr/local/bin/git-flow-feature
install: gitflow/git-flow-hotfix -> /usr/local/bin/git-flow-hotfix
install: gitflow/git-flow-release -> /usr/local/bin/git-flow-release
install: gitflow/git-flow-support -> /usr/local/bin/git-flow-support
install: gitflow/git-flow-version -> /usr/local/bin/git-flow-version
install: gitflow/gitflow-common -> /usr/local/bin/gitflow-common
install: gitflow/gitflow-shFlags -> /usr/local/bin/gitflow-shFlags
~

For installation instructions check out the link here: https://github.com/nvie/gitflow/wiki/Installation

Now that everything is setup. Here’s the quick getting started of creating a repo, linking it up to a remote and working in a repository. The first step is to initialize a new repo.

Continue reading “No excuse not to have your branching strategy taken care of, because: git-flow” →

Setting Up Github for Windows for Powershell CLI Users

Recently I installed the Github for Windows App. It’s a great app, however, I’d rather not use it for the day to day interactions I have with Git. I have a lot of branching, forking and merging to do that just doesn’t happen to well with the app. It’s a great app, but overall I’m just a few dozen times faster with the command line versus using an application.

So why did I download it and install it? The UI is great looking. I wanted to check it out and see how it worked, overall I’ve been fairly impressed. It’s not all that bad. The other cool thing about having it installed is it makes getting started on a fresh machine much faster with Powershell and such, however all the repos are setup with https instead of git as the path. This I’m not a fan of, so I threw this video together real quick to show how I remedy the situation.

Huboard, Github Issues ala Kanban, Implemented…

Recently I discovered Huboard. Thanks to those that helped me find it! Huboard is really simple and helps keep that kanban visibility when everyone can’t be in the same environment all the time. I setup a board for one of the pending OSS Projects that will be coming live. These are the steps I took. 1. Go to http://www.huboard.comand login with your Github identifiy. This will use your existing github account and you’ll then have access to all your projects to setup and use as you see fit with Huboard.

Allow Github to Provide Identify Access
Allow Github to Provide Identify Access

2. Huboard will now list all of your projects you have github.

Huboard Repository List (Click for full size image)
Huboard Repository List (Click for full size image)

3. Get your list items all labeled appropriately. (All explained below image)

Issues listed with appropriate Labels (Click for full size image)
Issues listed with appropriate Labels (Click for full size image)

The key to Huboard is the simple tagging. Each issue in the project will display as an open issue on the repository/project list in Huboard, however to get them to show up on the kanban there is a special label pattern to use. Simply add a number, dash, and the title of the issue for it to be listed in the kanban. Then apply the label(s) to the issue. For example, in the screenshot above you can see that item #3, which has a titled of “#3 – Initiate Project & Setup” also has a label of “2 – Ready”. This label will list the item in the column “Ready” on the kanban board. The same goes for each of the items that are listed as backlog. The kanban board in Huboard uses the number to order the columns by the labels and the following title as the column header. The respective kanban board for the issue listing above looks like this.

Huboard kanban (Click for full size image)
Huboard kanban (Click for full size image)

For now I’ve primarily been just adding the issues and maintaining them via the Github web interface. However the items can be moved via commit messages. Here are some examples;

  • push GH-#
  • pushed GH-#
  • move GH-#
  • moves GH-#

With that you get maximum Github Awesome + Kanban Communication.

Oh Snap, Got That Kanban w/ Github Integration!!

A recent issue came up on the team yesterday. We needed to increase the visibility of what we’re working on without dragging ourselves into more one on one or team communication. As anyone that has spent more than 5 minutes with a team knows, meetings kill productivity and morale, so the idea to get a kanban board going was brought up.

That raised the second issue of a remotely distributed team. We can’t have a real kanban board and the literal presence that it provides by being physical. The next best thing though is to have a virtual kanban board that integrates well into our workflow. With integration we get to look at it regularly and work around it to communicate where and what we’re working on without it becoming a major interruption.

That left the need for a kanban board with github integration. I thought to myself, “this exists right?” I checked the ole’ Internet tubes and sure enough someone had posed the question on StackOverflow! The question read, “What’s the best kanban tool to use with github?” Unfortunately there wasn’t a whole lot of answers or information following that up. However, the one answer that did exist provided an interesting solution.

Hubbard

The simple one page site is located here: http://huboard.com/ and on Github here: https://github.com/rauhryan/huboard. This describes the product a bit, and Ryan Rauh(@rauhryan) has a blog entry on Los Techies titled “Huboard – Github issues made Awesome“. You can also follow Huboard on Twitter @Huboard.

(Screenshots courtesy of Ryan’s Blog Entry, click any of them to go to his blog entry)

Huboard
Huboard

Huboard #2
Huboard #2

Where I’m At…

At this point I’m just checking it out, forking the code, and seeing how it works. This tool looks very promising however and fits into the workflow in an extremely seamless way!

Keeping Your Rails Projects Organized Right!

I’ve been working with Rails now for about 3 months. At first I jumped right in like a bull in a china shop. I have since, suffered the frustration of doing so. I’ve experimented on OS-X, Windows, and Linux (primarily the Ubuntu Distro). Among these three operating systems, getting up and running with rails is a breeze. Sure, I’ve wrecked more than a few apps I started, blown to smithereens a few machine images, and been generally destructive – but that’s not a bad way to learn at all. 😉

Through this trundling, I’ve come to find there are a few things that should be reviewed and learned thoroughly before smashing into the china shop (i.e. rails or Ruby for that matter). One of these tools is RVM. Another is Git. These tools, without doubt or question, you MUST LEARN! There is just too much value in both of these tools to try to ignore either one. First a quick description of each:

Git – Git is a source control server and respective client software.
 
RVM – Ruby enVironment Manager – RVM, sometimes referred to as the Ruby Version Manager also, is a way to maintain the various gems and other environment settings that are used for a particular project. It enables switching back and forth between versions of ruby, keeping ruby updated, and much much more.  In .NET, think of it as choosing which version of .NET to use, except with more power to go beyond just merely choosing which version. These two tools are pivotal in having a smooth, consistent, and understandable workflow. There is one other issue for Windows users here though, RVM does not and will not ever run on Windows. One can however install cygwin to get it running or they can use Pik.

Workflows

Below I have a short workflow tutorial, which I’ve broken out to getting started, working, and operational.

Getting Started

This is the first stage of any development project. Regardless of using PHP, Rails, .NET, Java, or whatever, there are certain things that need done. The key elements that I’ve found over the years include, not in any particular order;

  • Setup source control
  • Setup your environment
  • Start your basic project
After each of these things are done, and working together properly, it’s time to get coding. 🙂  First, setup a directory that will be the home for the entire project.

[sourcecode language=”bash”]
$ mkdir sampleWorkflow
[/sourcecode]

Next run the command to setup your environment for this specific project.

[sourcecode language=”bash”]
$ rvm –rvmrc –create 1.9.2@sampleWorkflow
$ cd ..
$ cd sampleWorkflow/
==============================================================================
= NOTICE =
==============================================================================
= RVM has encountered a new or modified .rvmrc file in the current directory =
= This is a shell script and therefore may contain any shell commands. =
= =
= Examine the contents of this file carefully to be sure the contents are =
= safe before trusting it! ( Choose v[iew] below to view the contents ) =
==============================================================================
Do you wish to trust this .rvmrc file? (/Users/adron/a_code/sampleWorkflow/.rvmrc)
y[es], n[o], v[iew], c[ancel]> yes
$ ruby -v
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin10.8.0]
$
[/sourcecode]

In the command above, rvm being the application, –rvmrc the parameter for what is being done, and –create is the command for the action to be taken. The 1.9.2 before the @ is the Ruby version and the value after the @ is the environment name, in this case being the same as the folder.

Once the command is run, move out and back into the folder to view how the rvmrc file will work. When you navigate into the directory again, the script will run, initiating the environment for Ruby 1.9.2. It will also ask to confirm if you trust the file. Running the ruby -v command to determine the version, will now display the active ruby version for this folder.

If you’re only using one version of Ruby, this might not seem that useful. But over time as you work with multiple projects, you will often find that different projects use different versions of Ruby. Sometimes 1.8.7 or jruby or rubinius. If that’s the case, rvm is a life saver in simplifying and keeping environments neatly organized.

Now that the environment is setup, we’ll need source control setup and as I generally prefer, an initial commit. Make sure to move into the directory that was just created. Issue the following git commands.

[sourcecode language=”bash”]
$ git init
Initialized empty Git repository in /Users/adron/a_code/sampleWorkflow/.git/
$
[/sourcecode]

With our directory now intialized for git, it is best to get a git .gitignore file created. (I know, that’s a lot of get gittin). Use mate, or whatever your editor is you prefer, and create a .gitignore file.

[sourcecode language=”bash”]
$ mate .gitignore
[/sourcecode]

At this point you’ll want to add something to the ignore file. I always start with the following basic files and folders to ignore. I’ve also written a short entry on what these files and folders are that I’m ignoring in the post Gotta Get Git.

[sourcecode language=”bash”]
#OS junk files
[Tt]humbs.db
*.DS_Store
.sass-cache/
.bundle

#Webstorm & Rubymine files
*.idea
.idea
.idea/

#Rails Heroku and other bits to ignore
*.sqlite3
db/*.sqlite3
public/system/*
.bundle
log/*.log
tmp/**/*
tmp/*
doc/api
doc/app
*.swp
*~
[/sourcecode]

Once that is entered, save the file and close. Next we’ll do our first commit. This is always a good practice, then there are no accidental commits of files that aren’t needed. Also note, I did not exclude the rvmrc file, this is needed to insure clarity about the environment when cloning the repository in the future.

[sourcecode language=”bash”]
$ git add -A
$ git commit -m ‘first commit’
[master (root-commit) ea81bed] first commit
3 files changed, 131 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
create mode 100644 .rvmrc
create mode 100644 .rvmrc.10.29.2011-11:33:32
$
[/sourcecode]

Now that this is recorded in source control history (not of course in the main repo, we’ll do that in a second) I like to go ahead and create the rails application. Move to a directory just below where the ‘sampleWorkflow’ directory is and create a rails application named the same thing. Since we already created the .gitignore file, we’ll be prompted to overwrite, which isn’t needed since the .gitignore is already setup correctly.

[sourcecode language=”bash”]
$ ls
sampleWorkflow someOtherAppOrSomething
$ rails new sampleWorkflow
exist
create README
create Rakefile
create config.ru
conflict .gitignore
Overwrite /Users/adron/a_code/sampleWorkflow/.gitignore? (enter "h" for help) [Ynaqdh] n
skip .gitignore
create Gemfile
create app
create app/assets/images/rails.png
create app/assets/javascripts/application.js
create app/assets/stylesheets/application.css
[/sourcecode]

…more stuff shows up…

[sourcecode language=”bash”]
create tmp/cache
create tmp/cache/assets
create vendor/assets/stylesheets
create vendor/assets/stylesheets/.gitkeep
create vendor/plugins
create vendor/plugins/.gitkeep
run bundle install
Fetching source index for http://rubygems.org/
Using rake (0.9.2.2)
Using multi_json (1.0.3)
Using activesupport (3.1.1)
Using builder (3.0.0)
Using i18n (0.6.0)
Using activemodel (3.1.1)
Using erubis (2.7.0)
[/sourcecode]

…more stuff shows up…

[sourcecode language=”bash”]
Using railties (3.1.1)
Using coffee-rails (3.1.1)
Using jquery-rails (1.0.16)
Using rails (3.1.1)
Using sass (3.1.10)
Using sass-rails (3.1.4)
Using sqlite3 (1.3.4)
Using turn (0.8.3)
Using uglifier (1.0.4)
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
[/sourcecode]

…and then when finished do a commit of the recent additions.

[sourcecode language=”bash”]
$ git add -A
$ git commit -m ‘Adding Rails 3.1 Project.’
[/sourcecode]

Now add the appropriate remote sources for git and the project is ready for development.

[sourcecode language=”bash”]
$ git remote add origin git@github.com:Adron/Kata-Coding-in-Rails.git
$ git remote -v
origin git@github.com:Adron/Kata-Coding-in-Rails.git (fetch)
origin git@github.com:Adron/Kata-Coding-in-Rails.git (push)
[/sourcecode]

The example, with extra example code in place, is available on @Github at https://github.com/Adron/Kata-Coding-in-Rails.

Operational

On a regular basis, while coding, one wants to commit their regular work and push those changes to the server (@Github in this scenario). After every change, add the changes to the commit, then commit with a message as shown. When done, do a pull to insure everything is up to date and then a push.

[sourcecode language=”bash”]
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add …" to update what will be committed)
# (use "git checkout — …" to discard changes in working directory)
#
# modified: Gemfile
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git add -A
$ git commit -m ‘updated Gemfile.’
[master b06aa76] updated Gemfile.
1 files changed, 0 insertions(+), 1 deletions(-)
$ git pull
Already up-to-date.
$ git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 289 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To git@github.com:Adron/Kata-Coding-in-Rails.git
6986cd0..b06aa76 master -> master
$
[/sourcecode]

Operational

This section, I’m going to primarily provide a bunch of links to specific instances of features for Git or RVM.

Git Branching

[sourcecode language=”bash”]
$ git checkout -b modify-branchSwitched to a new branch ‘modify-branch’$ git branch  master* modify-branch
[/sourcecode]

…make some changes…

[sourcecode language=”bash”]
$ git add -A
$ git commit -m ‘committing a minor readme.md file change while in a branch.’
[modify-branch 726e770] committing a minor readme.md file change while in a branch.
1 files changed, 3 insertions(+), 1 deletions(-)
$ git push
Everything up-to-date
$ git checkout master
Switched to branch ‘master’
$ git merge modify-branch
Updating b967d4e..726e770
Fast-forward
README.md | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
$ git branch -d modify-branch
Deleted branch modify-branch (was 726e770).
$
[/sourcecode]

Git Rebasing

Git Stashing

Managing Gemsets