-
Notifications
You must be signed in to change notification settings - Fork 3
CommitBestPractices
With any project that has more than one developer, and sometimes even when you have only one developer, it helps to have a clear pictures and process of how commits should happen to the source tree. I have the following recommendations:
- Whenever you have a new set of things you want to work on, first commit them to a branch clearly indicating the feature.
- Send an announcement about the feature to the forum, and get feedback.
- If everything works out, someone (maybe you) can merge it into the master branch.
This will keep the master branch as stable as possible for new features or additions.
I think it unnecessary on a project like this to worry about committing small things that should work everywhere to the master branch. Since there are few developers, it's probably better to get new features in first, and deal with the occasional instability rather than risk bogging down in too much work over small commits. If it seems like we can get a few developers who actively review commits though, then even small commits can go into separate feature branches and we can deprecate those branches once those features are merged.