diff options
Diffstat (limited to 'doc/topics/gitlab_flow.md')
| -rw-r--r-- | doc/topics/gitlab_flow.md | 26 |
1 files changed, 17 insertions, 9 deletions
diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md index eb298841247..7dd35419c76 100644 --- a/doc/topics/gitlab_flow.md +++ b/doc/topics/gitlab_flow.md @@ -311,7 +311,7 @@ In GitLab Flow, you can configure your pipeline to run every time you commit cha When you are ready to merge your feature branch, assign the merge request to a maintainer for the project. Also, mention any other people from whom you would like feedback. After the assigned person feels comfortable with the result, they can merge the branch. -In GitLab Flow, a [merged results pipeline](../ci/pipelines/merged_results_pipelines.md) runs against the results of the source and target branches merged together. +In GitLab Flow, a [merged results pipeline](../ci/pipelines/merged_results_pipelines.md) runs against the results of the source and target branches merged together. If the assigned person does not feel comfortable, they can request more changes or close the merge request without merging. NOTE: @@ -444,7 +444,7 @@ However, as discussed in [the section about rebasing](#squashing-commits-with-re Rebasing could create more work, as every time you rebase, you may need to resolve the same conflicts. Sometimes you can reuse recorded resolutions (`rerere`), but merging is better, because you only have to resolve conflicts once. -You can read a more thorough explanation of the tradeoffs between merging and rebasing [here](https://git-scm.com/book/en/v2/Git-Branching-Rebasing#:~:text=Final%20commit%20history-,The,-Perils%20of%20Rebasing). +The Git documentation has a thorough explanation of the [tradeoffs between merging and rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing#:~:text=Final%20commit%20history-,The,-Perils%20of%20Rebasing). A good way to prevent creating many merge commits is to not frequently merge `main` into the feature branch. Three reasons to merge in `main`: @@ -513,7 +513,7 @@ The words "change," "improve," "fix," and "refactor" don't add much information For more information, see Tim Pope's excellent [note about formatting commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). To add more context to a commit message, consider adding information regarding the -origin of the change, such the GitLab issue URL or Jira issue number. That way, you provide +origin of the change, such the GitLab issue URL or Jira issue number. That way, you provide more information for users who need in-depth context about the change. For example: @@ -543,9 +543,17 @@ In GitLab Flow, your can include automated CI tests in your branch or merge requ ## Working with feature branches -When creating a feature branch, always branch from an up-to-date `main`. -If you know before you start that your work depends on another branch, you can also branch from there. -If you need to merge in another branch after starting, explain the reason in the merge commit. -If you have not pushed your commits to a shared location yet, you can also incorporate changes by rebasing on `main` or another feature branch. -Do not merge from upstream again if your code can work and merge cleanly without doing so. -Merging only when needed prevents creating merge commits in your feature branch that later end up littering the `main` history. +Some tips for working with feature branches: + +- When you create a feature branch locally, always update your local copy of `main` before + branching off from it. +- When creating a feature branch, always branch from `main` unless you know your work + depends on some other branch. For example, to create `feature-x-update`, branch from + `feature-x` instead of `main`. +- If you merge in another branch after starting, explain the reason in the merge commit. +- If you have not pushed your branch upstream yet, you can still pull in new changes + by rebasing your local feature branch against your local copy of its parent branch. +- Do not merge recent changes from other branches into your local feature branch if your code + can work and merge cleanly without those extra changes. Each time you merge commits into your + feature branch, you add a merge commit to your feature branch. These merge commits + later end up littering the history in your `main` branch. |