diff options
Diffstat (limited to 'doc/topics/git/feature_branch_development.md')
-rw-r--r-- | doc/topics/git/feature_branch_development.md | 86 |
1 files changed, 86 insertions, 0 deletions
diff --git a/doc/topics/git/feature_branch_development.md b/doc/topics/git/feature_branch_development.md new file mode 100644 index 00000000000..ab3adf54dd7 --- /dev/null +++ b/doc/topics/git/feature_branch_development.md @@ -0,0 +1,86 @@ +--- +type: how-tos +--- + +# Develop on a feature branch + +GitLab values encourage the use of [Minimal Viable Change (MVC)](https://about.gitlab.com/handbook/values/#minimal-viable-change-mvc). +However, viable changes are not always small. In such cases, it can help to set up a dedicated feature branch. +People can contribute MRs to that feature branch, without affecting the functionality of the default (usually `master`) branch. + +Once work on the development branch is complete, then the feature branch can be finally merged into the default branch. + +GitLab frequently implements this process whenever there is an MVC that requires multiple MRs. + +## Use case: GitLab's release posts + +This section describes the use case with GitLab [release posts](https://about.gitlab.com/handbook/marketing/blog/release-posts/). +Dozens of GitLab team members contribute to each monthly release post. +In such cases, it may be more efficient to submit an MR on the release post feature branch instead of master. + +In this case, the feature branch would be `release-X-Y`. Assuming the `release-X-Y` branch already exists, you can set up an MR against that branch, with the following steps: + +1. Create a new branch (`test-branch`) against the feature branch (`release-X-Y`): + + ```shell + git checkout -b test-branch release-X-Y + ``` + + You should now be on a branch named `test-branch`. + +1. Make desired changes on the `test-branch`. +1. Add your changes, commit, and push to the `test-branch`: + + ```shell + git add . + ``` + +1. Commit your changes: + + ```shell + git commit -m "Some good reason" + ``` + +1. Push your changes to the repository: + + ```shell + git push --set-upstream origin test-branch + ``` + +1. Navigate to the URL for your repository. In this case, the repository is `www-gitlab-com`, available at `https://gitlab.com/gitlab-com/www-gitlab-com`. + + If needed, sign in to GitLab. You should then see an option to **Create merge request**: + + ![Create merge request](img/create_merge_request_v13_1.png) + +1. After you click **Create merge request**, you'll see an option to **Change branches**. Select that option. + +1. In the **New Merge Request** screen, you can now select the **Source** and **Target** branches. +In the screenshot shown, +we have selected `test-branch` as the source, and `release-13-0` as the target. + + ![Modify branches](img/modify_branches_v13_1.png) + +1. Once you've selected the Source and Target branches, click **Compare branches and continue**. + You should see an entry similar to: + + ```plaintext + New Merge Request + + From test-branch into release-13-0 + ``` + + An entry like this confirms that your MR will **not** merge into master. + +1. Make any additional changes in the **New Merge Request** screen, and click **Submit merge request**. +1. In the new merge request, look for **Request to merge**. You'll see an entry similar to: + + ```plaintext + Request to merge test-branch into release-13-0 + ``` + + That confirms you've set up the MR to merge into the specified branch, not master. + +1. Proceed with the change as you would with any other MR. +1. When your MR is approved, and an appropriate user merges that MR, you can rest assured that your work is incorporated directly into the feature branch. +When the feature branch is ready, it can then be merged into master. |