Blueprints are Git branches, that contain boilerplate code for all kinds of technologies and features. You can merge them together to start a new project. Their structure is optimized for avoiding difficult merge conflicts.
π· Blueprints follow a naming scheme (e.g. node/react/master), that shows the relationships between them and also indicate how changes are merged from one blueprint to another.
π Blueprints outline development workflows taking CI/CD and DevOps Best Practices into account.
π Blueprints document architecture, onboarding instructions and follow-up customization tasks.
π Projects created by merging blueprints together will be able to receive updates from those blueprints later.
Start a new Git repository:
git init foo
cd fooFetch the blueprints:
git remote add blueprints <blueprints-repo-url>
git fetch blueprintsList available blueprints (-r = remote branches):
git branch -rCraft something by merging blueprints into the new repository:
git merge blueprints/foo/master
git merge blueprints/bar/masterThere is an alternative way to merging if you don't want to inherit a blueprint's commit history:
git co blueprints/foo/master
git reset <local-branch>
git co <local-branch>
git add -A
git commitRefer to the README.md in your new repository to continue.
You can also list follow-up customization tasks by searching for TODO comments in the code:
grep -r "TODO" .Blueprint branches are Git branches, that have a hierarchical structure encoded in their branch name. Here are some examples:
βββββββββββββββ
β master β
βββββββββββββββ
β
βββββββββββββββ
β node/master β
βββββββββββββββ
β
βββββββ»βββββββββββ
β β
ββββββββββββββββββββββββββββββββββββββββ
βnode/angular/masterββnode/react/masterβ
ββββββββββββββββββββββββββββββββββββββββ
β
βββββββββββββββ»βββββββββ
β β
βββββββββββββββββββββββββββββββββββββββββββββββββ
βnode/react/redux/masterββnode/react/rxjs/masterβ
βββββββββββββββββββββββββββββββββββββββββββββββββ
This naming scheme shows the dependencies between the branches. For example, node/react/master is based on node/master, which means, that changes to node/master should always be merged into node/react/master.
The .../master suffix indicates the most stable version of a blueprint. However it is also possible to have other branches like .../feature-xy or .../develop on the same level.
Most blueprint branches are based on one parent branch. However it is also possible to have branches, which implement the combination of two blueprint branches if their combination requires some effort.
Here is an example:
βββββββββββββββ
β node/master β
βββββββββββββββ
β
βββββββββ»βββββββββ
β β
ββββββββββββββββββββββββββββββββββββββ
βnode/react/masterββnode/redux/masterβ
ββββββββββββββββββββββββββββββββββββββ
β β
ββββ³ββββββββββββββββββ
β
βββββββββββββββββββββββββ
βnode/react/redux/masterβ
βββββββββββββββββββββββββ
Those branches will receive changes from both of their parents.
To extend a blueprint foo/master, create a feature branch under foo/ with a short name, that summarizes the change (e.g. foo/extend-with-xyz). Implement your change within this branch, open a merge request / pull request against foo/master and wait for approval.
Now the new change in foo/master needs to be merged into all dependent branches. For a dependent branch called foo/bar/master, create a branch called foo/bar/extend-with-xyz and do the merge within this branch.
Think carefully if your contribution justifies the creation of a new blueprint.
Too many fine-grained blueprints will lead to a lot of merging and an increasing risk of difficult merge conflicts. Too few monolithic blueprints however limit reusability and decoupling.
Create a new blueprint foo/bar/master by branching it from its parent foo/master:
git co -b foo/bar/master foo/masterRename local branch:
git branch -m <old-name> <new-name>Rename remote branch:
git push <remote-name> --delete <old-name>
git branch <old-name> --set-upstream-to=origin/<new-name>