Commit 84b9aae9 authored by Sean Packham's avatar Sean Packham

Merge branch 'patch-23' into 'master'

Rephrase to enhance readability and some minor grammar in gitlab_flow.md

See merge request !11767
parents 7fea09bf 94673097
...@@ -67,7 +67,7 @@ With GitLab flow we offer additional guidance for these questions. ...@@ -67,7 +67,7 @@ With GitLab flow we offer additional guidance for these questions.
![Master branch and production branch with arrow that indicate deployments](production_branch.png) ![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. 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 there are many cases where this is not possible. This is possible for e.g. 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. 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. 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. In these cases you can make a production branch that reflects the deployed code.
...@@ -134,7 +134,7 @@ If the assigned person does not feel comfortable they can close the merge reques ...@@ -134,7 +134,7 @@ If the assigned person does not feel comfortable they can close the merge reques
In GitLab it is common to protect the long-lived branches (e.g. the master branch) so that normal developers [can't modify these protected branches](http://docs.gitlab.com/ce/permissions/permissions.html). In GitLab it is common to protect the long-lived branches (e.g. the master branch) so that normal developers [can't modify these protected branches](http://docs.gitlab.com/ce/permissions/permissions.html).
So if you want to merge it into a protected branch you assign it to someone with master authorizations. So if you want to merge it into a protected branch you assign it to someone with master authorizations.
## Issues with GitLab flow ## Issue tracking with GitLab flow
![Merge request with the branch name 15-require-a-password-to-change-it and assignee field shown](merge_request.png) ![Merge request with the branch name 15-require-a-password-to-change-it and assignee field shown](merge_request.png)
...@@ -173,9 +173,9 @@ It is possible that one feature branch solves more than one issue. ...@@ -173,9 +173,9 @@ It is possible that one feature branch solves more than one issue.
![Merge request showing the linked issues that will be closed](close_issue_mr.png) ![Merge request showing the linked issues that will be closed](close_issue_mr.png)
Linking to the issue can happen by mentioning them from commit messages (fixes #14, closes #67, etc.) or from the merge request description. Linking to issues can happen by mentioning them in commit messages (fixes #14, closes #67, etc.) or in the merge request description.
In GitLab this creates a comment in the issue that the merge requests mentions the issue. GitLab then creates links to the mentioned issues and creates comments in the corresponding issues linking back to the merge request.
And the merge request shows the linked issues.
These issues are closed once code is merged into the default branch. These issues are closed once code is merged into the default branch.
If you only want to make the reference without closing the issue you can also just mention it: "Duck typing is preferred. #12". If you only want to make the reference without closing the issue you can also just mention it: "Duck typing is preferred. #12".
...@@ -300,7 +300,7 @@ If there are no merge conflicts and the feature branches are short lived the ris ...@@ -300,7 +300,7 @@ If there are no merge conflicts and the feature branches are short lived the ris
If there are merge conflicts you merge the master branch into the feature branch and the CI server will rerun the tests. If there are merge conflicts you merge the master branch into the feature branch and the CI server will rerun the tests.
If you have long lived feature branches that last for more than a few days you should make your issues smaller. If you have long lived feature branches that last for more than a few days you should make your issues smaller.
## Merging in other code ## Working wih feature branches
![Shell output showing git pull output](git_pull.png) ![Shell output showing git pull output](git_pull.png)
......
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