diff options
| author | Mark Bowman <bowmandm21@gmail.com> | 2017-02-17 13:13:59 +0000 |
|---|---|---|
| committer | Mark Bowman <bowmandm21@gmail.com> | 2017-02-17 13:13:59 +0000 |
| commit | f98c2cf17f614111f623ace99042998480521424 (patch) | |
| tree | 55d9597ea434c975fbd1ff2e74e876e50e0f57aa | |
| parent | 5213ef23876e022b1303129c968f9af8f7904351 (diff) | |
| download | gitlab-ce-f98c2cf17f614111f623ace99042998480521424.tar.gz | |
Update gitlab_flow.md
| -rw-r--r-- | doc/workflow/gitlab_flow.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/workflow/gitlab_flow.md b/doc/workflow/gitlab_flow.md index c228ea72f22..4889e3ec50c 100644 --- a/doc/workflow/gitlab_flow.md +++ b/doc/workflow/gitlab_flow.md @@ -67,7 +67,7 @@ With GitLab flow we offer additional guidance for these questions.  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 there 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 App Store 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. In these cases you can make a production branch that reflects the deployed code. |