Create new branch from issue button

I see @dzaporozhets's solutions to the issue. Had it been introduced and after expelled?

@creamzy not sure. Feel free to think of a better solution.

@creamzy it was a prototype. Not implemented yet

Reassigned to @creamzy

Right now we have Related MRs under the issue description, and it would be logical to use the same place for Related Branch. Plus in this case we have no problems with the length of its name.

@JobV what do you think?

As soon as the branch is created, we hide New Branch btn

Assignee removed

Removed ~19492 label

Added frontend label

@creamzy makes sense!

Milestone changed to 8.5

@JobV great

mentioned in issue #2074 (closed)

I would love to see this feature. As was described some months back in Issue #2074 (closed) this feature is built into the Atlassian Jira product for its linking with Stash. In that context, the branch is named such as
bugfix/###-issue-title
And the name can be altered.

@dzaporozhets @JobV #2074 (closed) seems interesting but more complex than current suggestion. How do you think we should proceed?

@creamzy @dzaporozhets I prefer our light-weight approach and your mockup over atlassians.

I think you are spending too much time debating the character length of the branch. We live in a 64-bit world, now ;-) That aside, I would much rather have the freedom of a meaningful and readable branch name, than to be restricted to what you can fit in the UI. Just truncate the branch name text with an elipsis, and emit the full name with a mouseover. On the other hand, I may be oversimplifying your concerns.

My recollection is that Atlassian does have a character limit. But that limit does not include the prefix they apply to all branches created in Jira, bugfix/... It is very helpful to see issue-related branches with such a prefix, when you are listing branches. Those with bugfix/... are easily seen among the feature/..., master, hotfix/... and others. The GitLab issue ID may be helpful in providing the issue name on a mouseover, if that GFM is enabled for a branch name listing. But I prefer to browse the repository in GitLab, while doing more committing and such in a terminal. Unfortunately, any linking via GFM is not carried over to Git in a terminal. The prefixes help greatly in the terminal.

And yes, the full Atlassian feature may be more heavy-weight than what you apparently have described. But my reason for referencing Atlassian, and I believe also the reason why it was shown in #2074 (closed), was that the Atlassian feature is descriptive of something very useful. Its implementation in GitLab is something else, entirely.

I prefer our light-weight approach and your mockup over atlassians.

@JobV I agree. Lets keep it simple.

@creamzy your mockups looks great. Lets go this way.

According to branch name generation - keep it simple too: ID-issue-title.

Example:

Issue 213 with title "Fix 500 error" will be 213-fix-500-error

Branch name displayed only on issue page under Related branch section. No truncation or limitation needed

@dzaporozhets - the suggestion for the simple branch name generation, ID-issue-title, would be very helpful. Thank you for that consideration.

I still prefer to have more issue-type data in the generated name:

bugfix/ID#-issue-title;
feature/ID#-issue-title; or
hotfix/ID#-issue-title

But it seems that GitLab issues are not categorized in that way. That is unfortunate. Not all issues are bugs, and some follow a more critical path than others.

If the branch name that is generated can be modified, then this is mute; we can add a prefix as we see fit.

This issue should be implemented by Rails developer and then passed to Frontend for final touch.

Added ~127618 label

Some very large prospective customers have expressed interest in this feature. Looking forward to it.

@Haydn

@zj is working on the back end side of this, based on the mockup by @creamzy :)

mentioned in issue #13329 (moved)

Glad to see we're working on this, this function is still frequently mentioned as an advantage of Bitbucket https://news.ycombinator.com/item?id=11092598

@DouweM awesome

@dzaporozhets totally agree with your suggestion to use the full issue title, thanks!

@JayBofMA thanks for your comments

mentioned in merge request !2808 (merged)

@DouweM @zj I can not wait to see it alive

Reassigned to @zj

mentioned in issue #13878 (closed)

Milestone changed to 8.6

Status changed to closed by merge request !2808 (merged)

mentioned in commit cf2e3ff6

@JobV please add to feature comparison with GH

mentioned in issue gitlab-com/blog-posts#188

@zj can you please document this? I don't see documentation in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2808/diffs

Maybe a section in http://doc.gitlab.com/ce/gitlab-basics/create-branch.html is a good idea. Please elaborate on how the branch name is determined.

After the docs are done we should make a blog post https://gitlab.com/gitlab-com/blog-posts/issues/188

BTW If you create a merge request from a branch like this will it autofill the description with 'Fixes #XXXXXXX"?

Status changed to reopened

@sytses Ill get started on the docs.

BTW If you create a merge request from a branch like this will it autofill the description with 'Fixes #XXXXXXX"?

Any branch which ends with -XXXXX will amend the description with 'Closes #XXXXX'. So if I start a new branch to close this issue I could start a new branch local which ends that way to enable it without the button.

mentioned in merge request !3425 (merged)

We like the [NEW BRANCH] button, but we have an issue that prevents us from using it:

A new branch is currently auto-created from the master branch and we need to be able to pick a different target branch when clicking on the [NEW BRANCH] button, because our project has multiple sites and each sites is assigned its own milestone branch. We don't bring code into master until a release has been deployed to production.

Is this possible now or should I file a new feature request?

@dmoore1 Right now it will diverge from the default branch set on your project. So the use case you described is not supported.

But please feel free to open an issue and discuss it there, a new issue will also allow others to give their opinion more easily. When you open such an issue, could you cc me?

@zj Created #14905 (closed). Thank you.

Also, having issue number at the end of the branch name instead of the prefix makes it hard to find branches in a repo. IMHO, it's much easier to enter the issue number in the command line and then hit Tab to git autocomplete then trying to remember the words that the issue starts with.

@zj why is the id at the end of the branch name? it should be in the beginning I think, as was specified in this issue description. Can you change this?

@demisxbar @sytses

@JobV and I decided to move it to the end after discussion over Slack which we forgot to report back here.

Our thinking was that when working with git on the command line, it's much easier to use autocomplete with branch names that start with words you can remember, rather than with an issue ID.

If I was working on this issue "Create new branch from issue button", I would call the branch new-branch-button-3886 and autocomplete git checkout new-[TAB]. If I had 3886-new-branch-button, I'd have to look up the issue number.

If I, as a developer, had to start the branch name with the issue ID in order to benefit from the tighter "Related branches" integration, I would simply not do it and not use the feature, because I don't want to lose productivity on the command line.

IMHO, it's much easier to enter the issue number in the command line and then hit Tab to git autocomplete then trying to remember the words that the issue starts with.

Interestingly, @demisxbar mentions autocomplete as an advantage of starting with the issue ID.

I think the difference here is whether we're using autocomplete from the perspective of the branch's "owner" (who is more likely to remember the name they chose) or any other developers (who are more likely to see the issue ID in the browser, and find the branch that way). I think we should bias toward the developer's productivity here.

Edit: We could of course make the regex smarter and allow users to use either, see also https://gitlab.com/gitlab-org/gitlab-ce/issues/14910. I still think the button should default to adding the ID at the end, but maybe opinions here are diverse enough that we should make the default format configurable. See also https://gitlab.com/gitlab-org/gitlab-ce/issues/14590

I can speak from our team experience only. Everyone finds it easier to operate with issue numbers then remembering the first word of each issue branch name. Also, I can generally autocomplete by just typing first couple digits of the issue number vs. a few more letters, especially when a bunch of branches start with common words "create", "add" etc. If this could be something I could configure in the admin preferences that would be great. Something like "new branch naming convention".

mentioned in issue #14910 (moved)

@JobV @dzaporozhets What do you think?

@DouweM I don't think we should make it an option https://gitlab.com/gitlab-com/blog-posts/issues/161

I understand your point about the owner remembering but I think having it at the beginning is better since it are less characters to type.

Let's not reinvent the wheel and start with our users ask for and what is common in the industry.

@sytses Thank you for making customer feedback a priority. Appreciate it very much. To be fair to @DouweM and everyone else, I want to say that we've been using this new format (with issue number at the end) this week and it actually worked out better than I thought. Everyone got used to it pretty quickly, so maybe it's not a big deal after all. The bigger issue for us is not being able to select the base branch when creating a new branch from as reported in issue #14905 (closed). Thank you very much for your quick collaboration on this.

We cannot forget that this feature is not intended for the developer alone. Having the ticket number as a part of the branch is almost exclusively a team need in every organization I have worked. And the argument that autocomplete is easier with the number at the end is debatable. The command line is essential, for sure, but having the issue number at the beginning, and more visible, is a better feature for all, I would argue. Especially for those who might be using notification features such as email or Slack, where the number might be lost to truncation at the end.

@DouweM let's take a common way starting with number. I also don't remember issue ids but it looks like a standard and we don't want extra config option

@JayBofMA Great points. As far as the new branches go, if development is your default branch, can you set it as default in GitLab setting and then clicking on [New Branch] button should work for you too? If I am not mistaken, this button creates branches not from the master per se, but from whatever is set as default branch in your project settings. The reason this still doesn't work for us is that we have CMS project that tracks many sites within one installation, so we have many "default" branches (aka product branches) that development originates from -- one per each site. Our master is reserved for implementing global wide features that we can then backport to each product branch.

@zj can you do this before working on any other new branch items like https://gitlab.com/gitlab-org/gitlab-ce/issues/14566 and the new branch one?

@sytses Sure, its a small fix, so Ill try to have it in the next release and RC.

Status changed to closed by merge request !3425 (merged)

mentioned in commit 6bb71869

You guys are awesome!

mentioned in merge request !3708 (merged)

MR !3708 (merged) will put the iid first. Im confident it will be in 8.7

mentioned in commit 64776ab2

mentioned in merge request !3671 (merged)

mentioned in merge request !4218

@dzaporozhets I am curious about the reason to not make it a (project-based) config option to add the issuenumber as prefix or suffix?

I ask, because a lot of projects use branchname-prefixes to categorize types of branches, for instance 'feature/', 'bug/', 'refactor/'. For these projects the prefixing of the issuenumber interferes with the categorization prefix, whereas adding it as a suffix works perfectly.

We ourselves use categorization prefixes and in our current gitlab-version (8.6.1) the issuenumber is used as a suffix. We do not create branches from issues in gitlab, but with an external mechanism, but we do love the automated matching of issues and branches. I understand this will change in the next version and we will really miss the matching feature. Currently we are contemplating on not upgrading gitlab because of this, but I would prefer not to pin our gitlab version.

Would you be open to adding a project configuration option to influence the 'prefix/suffix issuenumber' behaviour?

Just my 2 cents. We've moved away from a categorization by the branch type a while back and it worked out great. One less thing for a developer to remember to do. The issue type is what defines the type of the work performed and the issue priority defines how quickly it moves forward. Currently, all our branches are generated from GitLab by clicking "New Branch" button and having issue number as a prefix makes them find and autocomplete much faster then before.

@demisxbar I see, and I fully understand why prefix was chosen, but I am not really contesting which approach is best. To each his own.

Also, I am in no position to make product decisions about Gitlab and was merely asking whether the configuration option will be considered, be it in CE or EE. We're using Gitlab CE, but would happily go to EE, if the functionality (or similar) was available there.

I ask, because I think there are at least two well-founded reasons to offer the suffix matching:

It's a change in behaviour of an existing feature. Because some businesses rely on this, that's usually done with a deprecation notice and grace period to allow migration, or with a configuration option.
Using a suffix is more flexible than prefix, because it more loosely couples branchnaming to Gitlab. This is under the assumption that namespacing of branches is usually done with prefixes. Such schemes are popular and branchnaming conventions are difficult to change because of tooling (even more so in big companies).

In case you're interested in our usage pattern, we do our branching from within our IDE, based on naming standards shared through the company. The IDE is our main hub in our workflow because it gives us the biggest flexibility in connecting all our tools. We love Gitlab, but it is part of a bigger tooling stack. Gitlab serves three goals for us:

git repository,
technical issue/version tracker,
code review tool through merge requests.

The automatic coupling of these three services through the branch naming was perfect. You see, the coupling is valuable, but it does not justify rewiring our entire toolchain.

@logicrebel Yes, totally understand each team has their own requirements and processes. In no way, I was trying to imply that our process is a panacea for all dev teams. Having a configurable branch naming pattern within GitLab would probably be the best solution for all. Thank you for sharing the details about your own process.

Sorry for warming up the closed issue, but I would like to suggest a solution for the problem, that the naming of the created branch does not fit every users needs.

Would it be possible to show a textbox with the branch name before creating it? So clicking the "New branch" button brings a textbox prefilled with "ID#-issue-title". The user then can accept the suggested name or adopt it to its needs, i.e. "bugs/ID#-issue-title" before the branch is created and linked to the issue.

We also prefer to have the branch naming convention to be globally configurable in settings with ability to override at the time of creation a new branch as @obma suggested. This should work for those teams who use different branch prefixes (or names) depending on an issue type.

mentioned in issue #20704 (moved)

Branch naming convention per project was also requested by the following customer: https://na34.salesforce.com/0016100000ZySY4

Mentioned in commit pfjason/gitlab-ce@cf2e3ff6

Mentioned in commit pfjason/gitlab-ce@64776ab2

Create new branch from issue button

Designs

Child items ...

Activity

Admin message

Admin message

Create new branch from issue button

Activity