Development of the application specifications shall be collaborative.
Efficiently doing so requires the definition of a process, which all involved persons must adhere to.
- main branch on GitHub: every commit is representing an official version, which is initiating further actions in neighboring domains (e.g. implementation or procurement)
- develop branch on GitHub: common base for all persons, who are involved into the specification process
- Short living feature, hotfix and release branches: separate places for advancing the specification before sharing results in the develop branch
- public repository: allowing virtually everybody to contribute either by formulation issues or addressing pull-requests, which are proposing concrete changes to the specification
- branch protection: all changes to the common base (develop branch) must be reviewed and approved by either ApplicationOwner or PlatformOwner, which both are able to directly alter the proposed contributions before merging
Many different workflows can be implemented based on Git and GitHub.
The proposed workflows are a bit more complex to apply in the beginning, but they are both comperably transparent and ease to debug (in case of "Kuddelmuddel").
- ApplicationOwner:
- will be assigned to be CodeOwner, which makes his/her approval necessary before merging into the common develop branch
- will apply the Gitflow Workflow
- Every other team member:
- will be assigned to be Collaborator, which allows e.g. to create issues, branches and pull-requests in the public repository
- will also apply the Gitflow Workflow
- Everybody else:
- repositories are public; 3rd parties might engage, but have to pull the code and work in their own repositories;
- will apply the Forking Workflow, which can be applied in most open source projects
<- Back to Introduction to Git and GitHub - - - Up to Preparing for Specifying Applications - - - Ahead to GitFlow ->