1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
---
stage: Create
group: Source Code
info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
type: how-tos
---
# Develop on a feature branch **(FREE)**
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 branch](../../user/project/repository/branches/default.md).
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 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 the [default branch](../../user/project/repository/branches/default.md).
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. Navigate to the [default branch](../../user/project/repository/branches/default.md) (here, `main`):
```shell
git checkout main
```
1. Make sure you have the latest version of your repository:
```shell
git fetch
git pull
```
1. Check out the feature branch:
```shell
git checkout release-x-y
```
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**:
1. After you select **Create merge request**, an option to **Change branches** displays. 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.
1. Once you've selected the Source and Target branches, select **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 your merge request's destination.
1. Make any additional changes in the **New Merge Request** screen, and select **Submit merge request**.
1. In the new merge request, look for **Request to merge**. An entry similar to this displays:
```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 the [default branch](../../user/project/repository/branches/default.md).
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 the [default branch](../../user/project/repository/branches/default.md).
|
