Don't develop in master branch. Just don't.

May I ask two questions, one on this post, the other git-related but to do with submodules?

Guess I kinda already did half huh. Sorry-kinda.
Why not develop on master (I'm guilty of doing this... yiiiiikes)?

Master branch should be the clean, definitive branch of your repo. You don't want WIP changes in master. This is especially important in a group workflow.

Read about the github git workflow for a good example.

Ah yeah, well I've been doing solo work and usually only push fairly stable updates. Not an excuse though. I will stop being naughty.
After this uncalled for asking a stranger how well versed they are in submoduling (is this appropriate? Not sure, been in my mom's basement for the last 7 years. joke).
Seriously, pardon my forwardness, but do you know about submodules? O_O

Also good practice is squashing commits when merging into master. It's boring in fact, but usually makes your repo history better.

FYI, 'git co' won't work for everyone. Unless they've set up the aliases. Might be worth mentioning :)

Git Flow is a great way to work with Git as well.

I usually develop all my small stuff in master for the initial version because if anyone looks at it then, they'll see something, instead of a blank repo (maybe with a terse README saying “yep, WIP”).

Then once I reach something that works, I have only working, stable code in master, and develop in branches.

This is probably only because I like to push to github often during development, for backup and early feedback purposes.

@passcod you are free to do things your own way, but I'd recommend working in small feature branches and making frequent small commits that get merged to master. This way, you get the benefit of a working master branch, and people checking your repo can see what works.

I've been burned by working in master, not realizing it, and then having a mix of working code and WIP that's a nightmare to try and figure out what should get committed. The worst part is that there is no clean version of master to go back to once you start working in it.

You can always pull master back to a sane state and move the work in progress stuff to a separate branch:

$ git checkout -b new-branch-name
$ git checkout master
$ git reset --hard <commit id of last known good state of master>

This will leave master pointing to your last known good spot, while leaving all your intervening work intact in the new-branch-name branch.