Merge branch 'patch-23' into 'master'
Rephrase to enhance readability and some minor grammar in gitlab_flow.md See merge request !11767
This commit is contained in:
commit
84b9aae9cf
1 changed files with 6 additions and 6 deletions
|
@ -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)
|
||||
|
||||
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.
|
||||
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.
|
||||
|
@ -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).
|
||||
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)
|
||||
|
||||
|
@ -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)
|
||||
|
||||
Linking to the issue can happen by mentioning them from commit messages (fixes #14, closes #67, etc.) or from the merge request description.
|
||||
In GitLab this creates a comment in the issue that the merge requests mentions the issue.
|
||||
And the merge request shows the linked issues.
|
||||
Linking to issues can happen by mentioning them in commit messages (fixes #14, closes #67, etc.) or in the merge request description.
|
||||
GitLab then creates links to the mentioned issues and creates comments in the corresponding issues linking back to the merge request.
|
||||
|
||||
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".
|
||||
|
@ -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 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)
|
||||
|
||||
|
|
Loading…
Reference in a new issue