Once you've got your hot new app up on GitHub, you want to work on it, but you're used to the Subversion world of update-code-test-update-commit. What does a good code cycle look like in Git?
My friends, I tell you I have the answer. And it's simple.
- git checkout -b nifty_name_for_nifty_new_feature
- git pull [repository [branch]]
- for each submodule of interest: cd path/to/submodule; git pull
- [code code code]
- [test test test]
- git add files/related/to/commit
- git commit -m 'nifty feature done'
- take 5 minute break to feed puppy or check roast in oven
- git checkout master
- git merge nifty_name_for_nifty_new_feature
- git branch -D nifty_name_for_nifty_new_feature
- git push
This keeps all development in tight little branches. The branches only exist locally, and go away when the feature makes its way to master. Happiness. Especially when teammates ask you to stop working on nifty_feature and fix acts_as_pointy_haired_boss. In that case, I recommend "fixing_bug_12345" as the branch name; that helps you remember what the branch does after you get back from the really boring meeting on how you can sell more purple pleather pants to Auckland this year.
No comments:
Post a Comment