diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-11-19 11:27:35 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-11-19 11:27:35 +0300 |
| commit | 7e9c479f7de77702622631cff2628a9c8dcbc627 (patch) | |
| tree | c8f718a08e110ad7e1894510980d2155a6549197 /doc/topics/gitlab_flow.md | |
| parent | e852b0ae16db4052c1c567d9efa4facc81146e88 (diff) | |
Add latest changes from gitlab-org/gitlab@13-6-stable-eev13.6.0-rc42
Diffstat (limited to 'doc/topics/gitlab_flow.md')
| -rw-r--r-- | doc/topics/gitlab_flow.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md index 8c5a2092a92..32676658bff 100644 --- a/doc/topics/gitlab_flow.md +++ b/doc/topics/gitlab_flow.md @@ -250,7 +250,7 @@ Atlassian has a more thorough explanation of the tradeoffs between merging and r A good way to prevent creating many merge commits is to not frequently merge `master` into the feature branch. There are three reasons to merge in `master`: utilizing new code, resolving merge conflicts, and updating long-running branches. -If you need to utilize some code that was introduced in `master` after you created the feature branch, you can often solve this by just cherry-picking a commit. +If you need to use some code that was introduced in `master` after you created the feature branch, you can often solve this by just cherry-picking a commit. If your feature branch has a merge conflict, creating a merge commit is a standard way of solving this. |