4 ms·

Simple git workflow with hack and ship

29 points by Superfud 16y ago

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 16y ago
Uh, his hack script is just "git pull --rebase". This is even the default when a fast-forward is safe.
- mechanical_fish 16y ago
  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?
  - deleted 16y ago
    [deleted]
  - tomstuart 16y ago
    git pull --rebase was added in 1.5.4, released in February 2008 (http://kerneltrap.org/Linux/GIT_1.5.4_An_Unusually_Long_Cycle http://kerneltrap.org/Linux/GIT_1.5.4_An_Unusually_Long_Cycl...).
- saurik 16y ago
  You can even make it always the default by setting branch.<name>.rebase to true, and can make /that/ the default by setting branch.autosetuprebase to always ;P.
DanielRibeiro 16y ago
This workflow would probably also benefit from a gitc script, for fast committing: #!/bin/bash git commit -a -m "$*"
e40 16y ago
The " || exit 1" is unnecessary. Just use "set -e" at the top of the script once.
- gruseom 16y ago
  Looking for more about this, I found a pretty good post: http://www.davidpashley.com/articles/writing-robust-shell-scripts.html http://www.davidpashley.com/articles/writing-robust-shell-sc...
  - Nick_C 16y ago
    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, &&.

29 points by Superfud 16y ago

jrockway 16y ago

Uh, his hack script is just "git pull --rebase". This is even the default when a fast-forward is safe.

mechanical_fish 16y ago
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?
- deleted 16y ago
  [deleted]
- tomstuart 16y ago
  git pull --rebase was added in 1.5.4, released in February 2008 (http://kerneltrap.org/Linux/GIT_1.5.4_An_Unusually_Long_Cycle http://kerneltrap.org/Linux/GIT_1.5.4_An_Unusually_Long_Cycl...).
saurik 16y ago
You can even make it always the default by setting branch.<name>.rebase to true, and can make /that/ the default by setting branch.autosetuprebase to always ;P.

DanielRibeiro 16y ago

This workflow would probably also benefit from a gitc script, for fast committing: #!/bin/bash git commit -a -m "$*"

e40 16y ago

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

gruseom 16y ago
Looking for more about this, I found a pretty good post: http://www.davidpashley.com/articles/writing-robust-shell-scripts.html http://www.davidpashley.com/articles/writing-robust-shell-sc...
- Nick_C 16y ago
  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, &&.