I am writing a simple framework that I want to open source just for experience (and fun!). However, it has some cool ideas that could make it grow to a larger project and I want to be ready if that ever happens. I highly doubt that that will happen, but I want to use this as a learning experience on how to properly run an open source project.
I want to dive right into the development. I’m not too worried about the actual code since it should be mostly simple. However, I’m not that experienced with Github. I mean, I know all the basics and such, but I don’t really know how to use all of the tools to my advantage.
How should I manage a workflow to best accommodate developers? I’m going to try to encourage the “standard” procedure:
- Fork the repository
- Clone the repository to your Git client
- Make a new branch for the work
- Do the actual work
- Commit your work (if multiple commits, rebase them to create one commit for easy history on the main repo)
- Submit a pull request with that one commit
Then, obviously, I will choose if I want to pull it or not. Here’s where I get stuck. How should I manage my branches?
I drafted up this design:
Proposed Workflow:
Basically:
- The
masterbranch is for stable releases. Individual pull requests are only sent to the master branch if it’s a critical bug and needs an individual release ASAP. - The
betabranch is for the code for the next stable release. Bug fixes will be pulled to this branch. - The
alphabranch is where the feature requests are added.
When a commit (not a pull request) is added to either the master or beta branch, the changes are “cascading” (i.e. a pull request is automatically created so that a commit to master will also be on beta and alpha; a commit on beta will be on alpha). I would do this with a simple script. Albeit it’d be somewhat ghetto, but it’d be automatic.
For a standard release, the beta would be merged into the master and then the alpha into the beta branch.
The reason for this is the feature requests aren’t put into the next version so they’re stable enough to be in the stable release.
Is this dumb? A consolidated “dev” branch would be the easiest to manage, but I’m afraid that some bugs would still get through. I guess I’d have to stop accepting feature additions a little bit before I release a new version.
EDIT: This question is extremely similar to my question: Is there an established or defined best practice for source control branching between development and production builds?. However, I’m looking at my proposed method vs. just not handling pull requests before a new release. Also, this is about open source software (so it might be harder to train new people on the system for this project).
3
There are many different approaches, and it depends both on your application and on your team’s personality. Here is a good summary of a few branching workflows in Git:
http://sethrobertson.github.io/GitBestPractices/#workflow
The link there labelled “Git-flow branching model” is a very popular approach.
However, there are some who think that all the process there is too cumbersome to really innovate. Read the last link under “Branch Workflows”: “Who needs process”.
That’s why I say it depends on your specific application and also on your personality/preferences.
Yes, use GitHub, it is the most popular and well-used. Have a public repo where you encourage people to commit on the beta branch. Don’t have too many branches where it gets confusing or unmanageable. Instead, if you want to see new versions of the framework, encourage them to fork it. You could consider consolidating your alpha and beta branches. Good luck!