Beginner’s Dogma

When working with git, the default work-flow is to use one master branch for everything. The integrity of local development keeps the master branch clean, which means it is assumed that before a push is made to the master branch everything should be in working condition. Another alternative that is commonly used is to make the master branch a work in progress that may or may not be broken (during development) at each commit and have tags when the current HEAD of the master is identified as significant enough for a “release”.

There are some severe shortcomings in the above two approaches:

• Collaboration is nearly impossible.  There’s no way to be explicitly aware of what feature or bug-fix an individual is working.  Also, working in parallel on two separate features is not possible because every commit can be shuffled with other commits from one or more different collaborator.
• No visibility of what features are being developed means no qualitative or quantitative measure of the progress of the development.
• Integrity of the master branch is not guaranteed
• Rollback of features to a commit before a new feature is integrated is not easy unless the release tags had well incremented improvements

Feature Driven Development

With this path, the master branch should always be clean and equipped to be “release-ready”. Development progresses by assigning each significant addition to the code to its own branch and then merged to master.

To begin with:

1. Create a git repo with the default branch as master, master is also protected
2. Add a readme and commit to master
3. Create a feature branch called setup
4. Add the least possible code necessary to begin development for individual features, this would include:
   • Start with an internal template
   • Tailor the template to a specific project
   • Include any required libraries
5. The setup branch can then be pushed to a remote origin which can then be reviewed by teammate
6. The reviewer can then merge the code to master when it is deemed ready

For a more detailed reference check out GitLab Workflow and GitHub