Github

Git branches are a way to work on different versions of a repository at one time.

The way I settled and found a good workflow is to have 3 branches:

• main is the development branch. It is the branch where all the new features are developed. Think it as the unstable branch.
• beta is the branch where the code is deployed to beta. It is the branch where the code is tested before going to production.
• stable is the branch where the latest stable version of the code is. It is the branch where the code is deployed to production.

Additionally you might want to skip the beta branch and deploy directly from main to stable. Or you might want to have an alpha branch where you test the code before going to beta, for very crowded projects.

To track the older versions of the code, you can use tags. Tags are like branches, but they don’t change after you create them.

I choose this workflow becuase I wanted to follow this priciples:

• Keep as few branches as possible to avoid confusion: Pretty straightforward principle. The more branches you have, the more confusion you will have. The higher the barrier to entry for new contributors that need to first learn how you structure the code base.
• Follow the organic growth of a project: When starting a brand new project, you will have only the main branch. Because of the nature of a pet project you dont need to add extra complexity by adding more branches. As the project grows, you simply add branches to support the new needs.
• Show the project is activily mainteined: Open source software has grown a lot in the last years. Developers want to see that the project is active and that the developers are working on it. Now is not uncommon to expect commits on a weekly basis. The main branch is the default branch people will look at. You want to show that the project is active.

General principles to keep while developing