

Simple git workflow with hack and ship - Superfud
http://object.io/site/2010/12/hack-and-ship/
Branches are virtually free with git, it makes a lot of sense to create short-lived feature-branches for each new thing you start working on. This does mean a bit of shuffling back and forth to integrate changes from others in your local work, but this “pull changes and rebase my work” workflow can be greatly eased by these small scripts.
======
jrockway
Uh, his hack script is just "git pull --rebase". This is even the default when
a fast-forward is safe.

~~~
mechanical_fish
What about "ship"?

Meanwhile, has `git pull` had a `--rebase` since the dawn of Git time in 2005,
or did it appear at one point?

~~~
tomstuart
git pull --rebase was added in 1.5.4, released in February 2008
([http://kerneltrap.org/Linux/GIT_1.5.4_An_Unusually_Long_Cycl...](http://kerneltrap.org/Linux/GIT_1.5.4_An_Unusually_Long_Cycle)).

------
e40
The " || exit 1" is unnecessary. Just use "set -e" at the top of the script
_once_.

~~~
gruseom
Looking for more about this, I found a pretty good post:

[http://www.davidpashley.com/articles/writing-robust-shell-
sc...](http://www.davidpashley.com/articles/writing-robust-shell-scripts.html)

~~~
Nick_C
Just be aware that using 'set -e', while good advice in general, won't catch
everything. Particularly lists and sub-shells may return with the status code
of the last command, not the failed command, depending on how they were used.
So it is possible a command failed within but won't trigger the -e.

The best way is to write the compound commands and any sub-shell commands so
that they will exit with the return status of any command that failed, using,
say, &&.

------
DanielRibeiro
This workflow would probably also benefit from a gitc script, for fast
committing:

#!/bin/bash

git commit -a -m "$*"

