Joined September 2012
·
Posted to
Don't develop in master branch. Just don't.
over 1 year
ago
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.
Achievements
172 Karma
2,013 Total ProTip Views
Honey Badger
Have at least one original Node.js-specific repo
Python
Would you expect anything less? Have at least one original repo where Python is the dominant language
Lemmings 100
Write something great enough to have at least 100 watchers of the project
Forked 20
Have an established project that's been forked at least 20 times
Altruist
Increase developer well-being by sharing at least 20 open source projects
Walrus
The walrus is no stranger to variety. Use at least 4 different languages throughout all your repos
Github Gameoff Participant
Participated in the Github Gameoff 2012 building a game based on git concepts of forking, branching, etc
24PullRequests Participant
Sent at least one pull request during the first 24 days of December 2012
Forked
Have a project valued enough to be forked by someone else
Mongoose 3
Have at least three original repos where Ruby is the dominant language
Charity
Fork and commit to someone's open source project in need
Mongoose
Have at least one original repo where Ruby is the dominant language
@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.