🆕 Create a branch for an issue in public beta

[dipree]

In an issue, you can now create a branch for that issue and start work right away. In the sidebar of an issue, branches connected to the issue are shown in the "Development" section, which has replaced "Linked pull requests". When you create a pull request for one of these branches, it is automatically linked to the issue. You can learn more about the functionality in our documentation.

Addresses github/roadmap#218 on our public roadmap.

We can't wait for you to try it out! Let us know what you think here in Discussions.

🐳

[Powersource]

this is nice. but i would prefer like gitlab has it, that it creates both a branch and a PR for you. one of the things that annoys me a lot when working on github. i like to take notes about my work in the PR but on github i can't do that before i already have 1 commit on the branch, something which doesn't always happen so fast.

[meysam101]

Okokok

[Hagimei]

I am in need of the V1.2 source codes to help fix a major error in all versions after 1.2. Please email to ( w3l01@aol.com ). I need the developers and editor version of the software to do a step by step debug of how the software handles math.. Thanks in advance and do not cancel this request.

[BellettiR]

@dipree Yup, that's the missing piece. While the feature itself is nice, the inability to draft a PR on a "no difference" compare i. e. on the prepared empty branch makes its utilisation way less useful. — Having the ability to draft a PR, i. e. start jotting down the outline and task lists, having prepared an empty branch for it at the same time, and linking both to the original issue is IMHO the ideal workflow that should be enabled in the future.

The need for a description (a brief, an outline, or an action plan; content like this) usually predates the first commit.

shouldn't be the issue discussion the right place where you can define how to implement it?

[janbrasna]

@BellettiR Usually issue tracks symptoms/repro, impact, deps… while PR describes reasoning/rationale, implementation, tests, and overall progress. Our workflow usually has input and prep for new branch/feature/PR before anyone touches the first line of code — exactly what this new branch functionality is for, just missing the ability to open a (draft) PR for this new empty branch right away.

[DevNatan]

It would be pretty awesome if it were possible to link an existing branch from another repository within the scope of the organization.

Where I work there is a certain repository of tasks where it is not possible to link Pull Requests or Branches because the projects are done in another repository, this would be an excellent addition.

[tpak]

We have the same challenge as @DevNatan - @dipree your suggestion, while interesting, means now 2 branches need to be tracked, merged, and cleaned up.

[Drufsen]

I was just thinking about the same thing. I think this functionality would make the feature a lot more useful.

[dipree]

We are currently looking into the linking of existing branches from within an issue. I'll keep you posted.

[MikeBeas]

@dipree Glad to hear this is something being investigated. I would like to throw my own 2 cents in here and say that when I create a branch called issue-2 from my git CLI, I would love if github could automatically match that to the related issue, rather than me having to go in and manually look it up on the issue and join them together.

[weiklr]

think other platforms seems to be way ahead in this, remembered i could intuitively link existing branches quite easily.

[Powersource]

Just noticed that when I do create a PR from the branch, it automatically links it to the issue and marks the issue for autoclosing when the PR is merged. This is something we don't want in our org so this is a bit annoying. E.g. we already have to write "for #123" in PRs instead of "fixes #123" to avoid the autoclosing, and this adds another thing we have to dodge.

[dipree]

Again, good feedback, keep it coming. This is not directly related but I will make sure to pass it on.

[duanestrong]

Now that I have been using it for a while I agree this is way too much almost hidden automation I can't control. I am unlinking the issue on the PR just before merge to stop it from auto closing the issue. Maybe options on the PR merge page on how you want to deal with linked issues?

[RihanArfan]

I do like the current behaviour so an option to choose would be fantastic

[spdrcd]

I totally agree because currently there are some other tests and other steps that needed to happen between when the main issue's branch's PR is closed and when the issue is closed. Right now there seems to be no way to adjust/modify this behavior at the moment.

[spdrcd]

somebody seem to have this issue in a ticket here
https://github.com/orgs/community/discussions/17308

[nicbet]

Finally! That's exactly the feature I've been waiting for - thanks for adding this to GitHub.

One small issue: when the issue title contains special characters (e.g., markdown backticks), it would be amazing if branch name could sanitize those out.

[700software]

@dipree. That's wonderful. Got a similar issue: #12290 (comment) Can that be fixed too?

[totoprayogo1916]

and whitespaces:

[kr2090]

It seems that this comment is similar to the one I just left. It would be nice to also include an automatic transcription from Cyrillic to Latin script. Thanks.

https://github.com/orgs/community/discussions/12290?sort=top#discussioncomment-7967829

[ADTC]

@dipree the sanitization should be based on a whitelist (list of allowed characters, disallow everything else) not a blacklist (list of disallowed characters, allow everything else). I hope by now it is. :)

[SimonWoidig]

We have a similiar problem. If the issue title contains diacritics, the branch will then contain diacritics. We want to keep diacritics in the issue title but have the branch name sanitized.

[rdoddanavar]

Not within the scope of this feature currently, but in the future it would be neat to see:

• The existence of any branches associated with the issue appear in the main "Issues" page, similar to how the PR icon shows up. This would help to differentiate between active and inactive issues (similar to Azure Devops)
• The creation of a development branch show up in the timeline of a specific issue, similar to other events (commits, comments, tags, etc.)

Great work guys

[TomaszGasior]

I can't assign existing branch (new-design) to the issue: TomaszGasior/RadioLista-v3#116. It's only possible to create branches and choose PRs, no way to just select existing bare branch.

[stiliajohny]

It would be great if we can configure some sort f regex when it comes to the naming convention of the branch as well as limit or unlimit the name length of the branch

For example.

bug/issue-name/123
or to kind of generalise that
[label]/name/[ticket number]

[ChristopherBanas]

Came here to suggest this as well, Jira allows you to edit the naming convention for automatic branch creation.

[ryancraigdavis]

I wanted to second (or third, fourth, etc) this comment. As @Th3S4mur41 said earlier, having the ability to auto import something related to your branch protection or organization's rulesets would be very helpful.

[jkazimierczak]

One of the conventions for such naming is defined in Conventional Commits and could be used as a prefix for a new branch.

[tw0shoes]

It's been 2 years now, is this possible? Is there anyone working on it?

[laceysanderson]

Yes! I came to to suggest exactly the same thing! I can't find any documentation suggesting it was every implemented :-( Please GitHub! We have very particular naming conventions for our repo and right now it is a pain to delete the long suggested option and then manually enter our version. It is a very specific pattern so would be easy to configure if such an option existed :-(

[Jared-Dev]

Could we get the option to move a projects story to the correct column when using the create branch feature?

A story/issue is in the Todo column. Once the branch is created the story is then moved to the "In Progress" column.

[dipree]

That's indeed a great suggestion. This currently limited by the Projects Beta which doesn't allow this yet. But once it does we can support this is an option.

[tdtm]

We'd like to see the ability to configure a default repository destination.

We've got a two-repo structure for all projects to separate project management and source*.

So for a ticket in the foo-project repo, branches will always be in the foo-source repo. Now we can use the dropdown, but making it configurable will avoid occurences of distractingly creating it in the wrong repo, and just reduce the number of clicks we have to do every time.

---

On a related note, being able to configure the default branch would also be nice.

Something a bit more complex: configuring the default branch source (and branch name) based on labels.
Examples:

• a hotfix label means a branch named hotfix/1234-broken-thing off the main branch.
• a feature label means a branch named feature/5678-awesome-new-thing created off the nightly branch.

[dillingham]

If not by label, then at-least multiple branch name templates with a title that becomes a button in the modal

[gr2m]

Love the feature! But I think I ran into a bug?

My issue title is something like "🐛 [Foo] Bar" which suggests a branch name 42-🐛-foo-bar. Which works. But after checking out the branch locally, I'm not able to push, it fails without any helpful error message

[dipree]

We are now sanitizing the branch name more strictly so this shouldn't happen anymore.

[marconneves]

This is amazing, it working very good! But have a stranger behavior, when have " - " in name of issue, type "Product - Create Variants", in name of branch get 3 "-", type "52-produtos---create-variants"

[dipree]

Thanks for the feedback, this has been fixed.

[zefir-git]

Linking to an existing branch would be great.

[Disabled-Temporarily]

You can link an existing branch from here

[zefir-git]

That links an existing PR, not a branch

[Disabled-Temporarily]

I like this feature, and it would be better if we can add the feature type to the branch name like <ref>-<type>-<issue name> instead of <ref>-<issue name> the type could be a value like feat/bug/docs/...

[robvanderleek]

Not sure if I'm allowed to post this again but I guess there will always be features not covered by the platform itself.
This is my second (and last) post here to inform GitHub users there's an App/Action called Create Issue Branch that supports many features requested above, such as:

• Configure branch name format
• Configure default source branch
• Configure source branch based on label
• Automatically open a (draft) Pull Request
• Copy over attributes (such as labels and milestones) from the issue to the (draft) PR
• Configure PR target branch based on issue label
• Feature requests are always welcome!

FD: I'm the author of that app.

I think the current "Create a branch" functionality in the platform is a great starting point for most development workflows (and most likely sufficient for many projects), but if you're looking for more control please consider the Create Issue Branch App/Action.

[georgebuilds]

Huge +1 on the configuration of the default source branch used for this modal.

[700software]

✔ fixed

Default branch name should include numbers from issue title

Default branch name is currently in format of issuenum-words-from-issue-title e.g. 123-client-fix-broken-grapple

But in this example, the original issue title is Client 12 fix broken grapple. the devs are now always editing the branch name to add the client number.

The branch name they want is 123-client-12-fix-broken-grapple

Can we get number as allowed character in default branch name please?

We have the same problem with both client numbers and report numbers being omitted.

[BellettiR]

default branch name should be customizable! let's try not to make the same mistake as in gitlab ce :)

[Bestra]

Can we get number as allowed character in default branch name please?

@700software we just deployed a fix for that this morning, thanks for bringing it up!

[ollejernstrom]

Save the users option so that if i want to always check out locally, please do not pre select code space every time so i cannot quick copy the cmd.

[AlgyTaylor]

I really like the 'create a branch' feature, and find it really useful. One thing that I'd love is being able to slightly change the branch naming convention. At the moment it defaults to (in my case) 630-upgrade-webpack-dev-server. This means me going in and manually changing it to gh-630/upgrade-webpack-dev-server to fit my own conventions. That's fine, it's next to no work, but it'd be amazing if I could get it to do that automagically! :)

Great feature though - it's so useful :)

[vbrozik]

The function is great! I just found that it is annoying that the created branch name is not consistent between the VS Code extension GitHub (specifically the Start Working on issue function) and this function of the GitHub web interface. For example I have an issue named "Deny rules replacement creates redundant rules" with the issue number #61.

• GitHub "Create a branch for this issue..."
  creates a branch named 61-deny-rules-replacement-creates-redundant-rules
• VS Code GitHub Pull Requests and Issues extension "Start Working on issue"
  creates a branch named issue61

Personally, I prefer the descriptive naming convention used by the GitHub web interface. In my opinion, the ideal solution would involve an API call for branch creation, which the VS Code extension could utilize. Currently, these two functions, developed by the same company, exhibit incompatibility.

In the repository of the extension there are issues related to this problem:

• On Issue, "checkout topic branch" should use existing branch if already created in UI microsoft/vscode-pull-request-github#4509
• Detect when the branch name looks like it references an issue microsoft/vscode-pull-request-github#4120
• Enhancement request: Detect already-linked PR branches when selecting an issue microsoft/vscode-pull-request-github#2243

Improved coordination among the GitHub development teams would be highly beneficial! 🚀

[cyfyifanchen]

I like this feature a lot, I no longer have to scratch my head for how to name my branch.

Well, there's a tiny problem, git fetch origin {name of branch} then git checkout {name of branch} seems taking too long. I encounter the following error every single time.

For better UX, I would suggest to add an option, where I can opt out on git fetch origin {name of branch} and only copy {name of branch}. That way, I can have the git fetch originwait time postpone togit push origin` when the local change committed. That's better UX I think, the user is prepared for the wait time before it happens.

Another thing is, checkout to the Github Desktop Client crashes quite often due to the long wait time.

[Bugs5382]

One thing I would add is a setting for a "default" branch to be customized to a different default. I understand that main is my default branch, however I keep main for production and use develop to build features from.

Just food 🥘 for thought 🧠

[georgebuilds]

Huge +1 on this request. We use it the same way. Always branch from development and merge back into it

[jay-babu]

Sorry, the source branch 70-sales-history-per-item could not be found.

Getting this error when trying to create a branch when switching repositories for an issue

[Alexandria-Davis-Ametek]

This issue seems to be more likely to occur if the branch name changes even a little bit. So while 70-sales-history-per-item sometimes works without issue, 70-sales-history-per-item-1 is more likely to have the issue, and 70-fix-sales-history-structure would also likely cause the problem.

This problem is frequently experienced when dealing with dependencies in our repositories.

[Alexandria-Davis-Ametek]

I think I found the exact behavior that causes it for me?

If you create a branch, then create a second branch in the same session, that causes the issue reliably.

[kr2090]

Excellent functionality. However, branch names in Git should be exclusively in English. It would be great to add automatic transcription from other languages, particularly from Slavic languages. Task names can be in different languages if it's a team's norm, but branch names should always be in latin. Thank you for your attention.

[vbrozik]

add automatic transcription from other languages

I think you meant "transcription from non-latin scripts"? There is no universal transcription or transliteration (these are two distinct things) between scripts. Both the transcription and transliteration depends on languages.

For example if we consider cyrillic then for example the letter "и" will in most cases be both transcribed or transliterated to latin as "y" for Ukrainian but as "i" for Russian.

• https://en.wikipedia.org/wiki/Romanization_of_Russian#Transliteration_table
• https://en.wikipedia.org/wiki/Romanization_of_Ukrainian#Tables_of_romanization_systems

[ADTC]

I think this is out of scope. If Git supports creating branch names with these characters, then there is no need to do the suggestion. Besides, it is a dangerous rabbit hole to go into, as you can end up completely altering the meaning and unintentionally offending people. It's best to just stickle with the exact title text, and do the bare minimum to make it a valid branch name. Anything beyond that should be left to the user's discretion. As a user, you can just edit the name if you don't like it.

[jay-babu]

instead of selecting a single repository. it would be nicer if i could select all my repositories then submit which would create all the branches. if a user wanted different names, they could still select one and create multiple times

[ADTC]

I don't think I understand what you mean here. 🤔

[jackkoskie]

I would like it to remember the "what next" option for next time so that I don't have to select github desktop every time

[kumilanka]

I can't figure out why I can select some existing branches in the repository to link to an issue, but not the one I created by hand for it. I can see it in the repository. It complains if I try to use this feature to create a branch with the same name. But it does not allow me to link the branch I want. Seems bugged.

[fishforyou]

I would display the branch source selector by default, without requiring clicking an extra link. I forgot a few times to link to some other branch I use (e.g. "dev", "staging") and was working directly on source from "main" by mistake.

[ADTC]

Yeah such an unnecessary step. They could even just put the repo dropdown and branch dropdown in the same row. There's plenty of space to arrange it that way.

[justinmann]

Add a "Open branch with VS Code".

[beroff]

Please consider placing the "Create branch" button on the same pop-up pane as the rest of the dialog, to make it a bit easier to find and use. The current placement, as shown below, does not feel as intuitive, IMHO. Thank you.

(Apologies if I missed something; I'm pretty new to git and GitHub.)

[ADTC]

It doesn't look like that for me. The button is inside the white box, not floating outside. Have you tried reloading the page?

[beroff]

Yes, and it's reproduceable. But I figured out what's happening. The white pane box is avoiding the bottom edge of the browser window, but the Beta/Share/Create elements do not. When I change the Zoom level, or alternatively the size of the browser window, the white pane box adjusts accordingly.

[markusfalk]

I have applied a rule set to the branch names and now I get the following error when creating a new branch via this feature:

Sorry, there was an error creating the branch.

the rule is: ^\d+\/[a-zA-Z_]+-[a-zA-Z.]+$ which is matching the provided name 12/bug_foo-markus.falk

Any ideas?

Thank you!

[markusfalk]

It would also be nice if the default branch name already used "folders" (/) for the branch name issue number:

• 1/foo
• 1/bar
• 2/foo

A lot of tools support this to give more oversight and group things together