Commit 0f35c61d authored by Job van der Voort's avatar Job van der Voort

add graphs to git-flow article

parent 6f61cbd1
...@@ -44,7 +44,7 @@ And doing releases doesn't automatically mean also doing hotfixes. ...@@ -44,7 +44,7 @@ And doing releases doesn't automatically mean also doing hotfixes.
# GitHub flow as a simpler alternative # GitHub flow as a simpler alternative
![Master branch with feature branches merged in]() In reaction to git flow a simpler alternative was detailed, [GitHub flow](http://scottchacon.com/2011/08/31/github-flow.html). ![Master branch with feature branches merged in](github_flow.png) In reaction to git flow a simpler alternative was detailed, [GitHub flow](http://scottchacon.com/2011/08/31/github-flow.html).
This flow has only feature branches and a master branch. This flow has only feature branches and a master branch.
This is very simple and clean, many organizations have adopted it with great success. This is very simple and clean, many organizations have adopted it with great success.
Atlassian recommends [a similar strategy](http://blogs.atlassian.com/2014/01/simple-git-workflow-simple/) although they rebase feature branches. Atlassian recommends [a similar strategy](http://blogs.atlassian.com/2014/01/simple-git-workflow-simple/) although they rebase feature branches.
...@@ -54,7 +54,7 @@ With GitLab flow we offer additional guidance for these questions. ...@@ -54,7 +54,7 @@ With GitLab flow we offer additional guidance for these questions.
# Production branch with GitLab flow # Production branch with GitLab flow
![Master branch and production branch with arrow that indicate deployments]() GitHub flow does assume you are able to deploy to production every time you merge a feature branch. ![Master branch and production branch with arrow that indicate deployments](production_branch.png) GitHub flow does assume you are able to deploy to production every time you merge a feature branch.
This is possible for SaaS applications but are many cases where this is not possible. This is possible for SaaS applications but are many cases where this is not possible.
One would be a situation where you are not in control of the exact release moment, for example an iOS application that needs to pass AppStore validation. One would be a situation where you are not in control of the exact release moment, for example an iOS application that needs to pass AppStore validation.
Another example is when you have deployment windows (workdays from 10am to 4pm when the operations team is at full capacity) but you also merge code at other times. Another example is when you have deployment windows (workdays from 10am to 4pm when the operations team is at full capacity) but you also merge code at other times.
...@@ -68,7 +68,7 @@ This flow prevents the overhead of releasing, tagging and merging that is common ...@@ -68,7 +68,7 @@ This flow prevents the overhead of releasing, tagging and merging that is common
# Environment branches with GitLab flow # Environment branches with GitLab flow
![Multiple branches with the code cascading from one to another]() It might be a good idea to have an environment that is automatically updated to the master branch. ![Multiple branches with the code cascading from one to another](environment_branches.png) It might be a good idea to have an environment that is automatically updated to the master branch.
Only in this case, the name of this environment might differ from the branch name. Only in this case, the name of this environment might differ from the branch name.
Suppose you have a staging environment, a pre-production environment and a production environment. Suppose you have a staging environment, a pre-production environment and a production environment.
In this case the master branch is deployed on staging. When someone wants to deploy to pre-production they create a merge request from the master branch to the pre-production branch. In this case the master branch is deployed on staging. When someone wants to deploy to pre-production they create a merge request from the master branch to the pre-production branch.
...@@ -81,7 +81,7 @@ An 'extreme' version of environment branches are setting up an environment for e ...@@ -81,7 +81,7 @@ An 'extreme' version of environment branches are setting up an environment for e
# Release branches with GitLab flow # Release branches with GitLab flow
![Master and multiple release branches that vary in length with cherrypicks from master]() Only in case you need to release software to the outside world you need to work with release branches. ![Master and multiple release branches that vary in length with cherrypicks from master](release_branches.png) Only in case you need to release software to the outside world you need to work with release branches.
In this case, each branch contains a minor version (2-3-stable, 2-4-stable, etc.). In this case, each branch contains a minor version (2-3-stable, 2-4-stable, etc.).
The stable branch uses master as a starting point and is created as late as possible. The stable branch uses master as a starting point and is created as late as possible.
By branching as late as possible you minimize the time you have to apply bugfixes to multiple branches. By branching as late as possible you minimize the time you have to apply bugfixes to multiple branches.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment