It's no secret I am a fan of git, but even moreso of Github.

Recently though I've been using hub as my command-line interface to Github (and therefore, git as well). The ability to generate pull-requests from the command line saves a lot of clicking and interfacing through the website.

However, it's syntax leaves much to be desired. But why are pull-requests so important you ask? Code review, obviously.

Back in the mid-fall we hired a former Hooters-wing-eating-contest-champion/dev-ops/front-end/Vermonter as the result of the outfall of a sadly demised fellow New York start-up. One of the first things he implemented (along with setting us up with a lovely chef automation system) was our new workflow. Until JT came along, the other developer and I were mere git neanderthals — working primarily in the master branch, with only occasionally making new branches for radical changes. His suggestion was to set up the following:

• master would be the version of what is on our production server
• preview would be the version of what is on our preview/qa server
• development would be the core base of what we work on (and what also will soon exist on our continuous integration server, but more on that later)

We would hence forth ONLY work on branches — each ticket in our tracking system (JIRA if you must know, and thank you MTV for training me on how to use it over four years) would become a new branch modeled after [ticket type]/[ticket ID]. So, bug number 123 in the WEB project in Jira would become bug/WEB-123. If multiple developers are working together to write a new feature, we first branch that feature off of development as feature/awesome_new_project, and then we all make our branches off of that for each ticket. Each time the ticket is complete, we make a pull-request back to the "parent" branch (either development or the feature/awesome_new_project branch).

The complexity of this graph shows we're very productive

These pull-requests serve two primary purposes:

• a break-point to roll back a bad merge
• mandatory code review!

Whenever a pull-request is made, the creator of the pull request is not allowed to merge that pull-request into the branch until one of three conditions have been met: they either need to receive "cake" (:cake: in the Github comment field), have resolved/answered all of the questions posted to the pull-request, or 24 hours have passed since the pull-request was generated. This allows all of us to get better insight into what other people are working on, and have a good chance to point out things that we would have done differently, or might have solved in alternate methods in other places in the code. Remember: above all else, consistancy.

Alas, making pull-requests, even with hub, is time consuming! There is just so much typing!

But, good sirs, this is also where my love of bash enters the picture. With a quick function defined in my .bash_profile, making pull-requests is even easier.

function pr (){
    git_branch=$(git branch 2>/dev/null | sed -n '/^\*/s/^\* //p')
    git pull-request "$@" -b [github owner]:development -h [github owner]:$git_branch
}

This will cause a pull-request to be generated for the currently checked-out branch back into the development branch of the repo (obviously replace [github owner] with your github code owner's username), so instead of typing out all that malarky I can just type pr "adding foobaz to the frutz".

Of course with all this branching, you need to make sure you're pulling from the correct place, which leads to this function:

function branch (){
    args=("$@")
    if [ -n "${args[1]}" ]
    then
        git stash
    fi

    git checkout development && git pull && git checkout -b ${args[0]}

    if [ -n "${args[1]}" ]
    then
        git stash pop
    fi
}

(I'm postive there's a more bash-y way to do those tests to see if you should stash, but this works for all intents and purposes).

This allows you to create a new branch off development, and if you've done any work that needs to be on that branch, stash it, update from development, create your branch and then apply your stash on top of the new branch. Nifty.