This is Git scheme and architecture. Its purpose is to ensure
Last, any scheme must also avoid getting too technically weird or complicated.
Our scheme consists of two telescopic branches.
The master repository will be respected for sources that both build and execute flawlessly except for unforeseen bugs. At end of a release, once release-level quality assurance has blessed it, it's pushed to an appropriately named copy (in the illustration here, v1.0, v1.1, etc.).
This branch is a "sacred" area. The following is always true.
The master branch...
Branch master is what developers git clone each for him- or herself.
Pushing code to the master branch that doesn't build is considered a cardinal sin as is pushing code that breaks existing functionality. The code in this branch may contain references, however, to functionality that may be incomplete or non-existent. Such references may lead to an abnormal situation, but usually not including a crash.
At some well defined point, even multiple times per day in the case of very small tasks, a developer may merge his personal branch into master Developers might frequently pull changes each other has made from master down to their personal branches. If a developer is working in a personal branch on a particularly ugly change, he or she may not merge into master until the end of a sprint, or later still.
These are branches, considered profane or "unsacred", named any way their (developer) creator wishes who may create any number of such branches he or she wishes. They may be broken 6 ways from Sunday and remain that way. Developers may git push and git pull between each other with no restrictions.
Please refer to the illustration below. The dotted lines group content on a per-host basis. Unlike other source-code or -version control systems, Git is not "client-server". To the extent that we observe a "client-server" relationship in our repositories in which the clients are the individual development hosts.