New customer portal: help.github.com 🚢 #206502
Replies: 11 comments 1 reply
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
|
Amazing work Github team |
|
This is greatly useless. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
This looks like a really useful improvement! 🚀 Having support, documentation, learning resources, community, and account information available through a single portal should make finding the right resources much easier. The Copilot-powered search is especially interesting. It would be great if the search could continue improving with more context-aware results and direct links to relevant documentation or troubleshooting steps. Looking forward to trying out the new experience once it becomes available for my account. 👍 |
A promising direction for GitHub SupportCentralizing support, documentation, learning resources, community content, and account-related information behind a single portal is a significant architectural improvement. The Copilot-powered search is particularly interesting because the main challenge with GitHub support has historically been discoverability, rather than the absence of documentation. A unified search layer could reduce the need to determine first whether an issue belongs to GitHub Support, Community Discussions, Docs, or the status system. One feature that would make this especially useful is context-aware troubleshooting. For example, when a user searches for a specific error, the portal could surface:
It would also be valuable if search results clearly distinguished official documentation from community-generated answers, so users can immediately understand the authority and freshness of the information. Since the rollout is gradual, feedback on search relevance, result quality, and navigation between these resources should be particularly useful during this phase. Looking forward to seeing how |
|
Hi @github ,one thing that could make the new portal especially useful is giving search results more context from the user’s actual issue. For example, if someone searches an error or billing problem, it could show the relevant docs, current incidents, known limitations, and the correct support path together. It would also be helpful to clearly distinguish official GitHub guidance from Community answers so users know which information is authoritative. The unified portal looks like a good step toward making GitHub support easier to navigate. 🚀 |
|
|
|
git log origin/main --grep="test: activity" |
Basic writing and formatting syntaxCreate sophisticated formatting for your prose and code on GitHub with simple syntax. HeadingsTo create a heading, add one to six # symbols before your heading text. The number of # you use will determine the hierarchy level and typeface size of the heading. # A first-level heading
## A second-level heading
### A third-level heading
When you use two or more headings, GitHub automatically generates a table of contents that you can access by clicking the "Outline" menu icon within the file header. Each heading title is listed in the table of contents and you can click a title to navigate to the selected section.
Styling textYou can indicate emphasis with bold, italic, strikethrough, subscript, or superscript text in comment fields and
Quoting textYou can quote text with a >. Text that is not a quote
> Text that is a quoteQuoted text is indented with a vertical line on the left and displayed using gray type.
Note When viewing a conversation, you can automatically quote text in a comment by highlighting the text, then typing R. You can quote an entire comment by clicking , then Quote reply. For more information about keyboard shortcuts, see Keyboard shortcuts. Quoting codeYou can call out code or a command within a sentence with single backticks. The text within the backticks will not be formatted. You can also press the Command+E (Mac) or Ctrl+E (Windows/Linux) keyboard shortcut to insert the backticks for a code block within a line of Markdown. Use `git status` to list all new or modified files that haven't yet been committed.
To format code or text into its own distinct block, use triple backticks. Some basic Git commands are:
```
git status
git add
git commit
```
For more information, see Creating and highlighting code blocks. If you are frequently editing code snippets and tables, you may benefit from enabling a fixed-width font in all comment fields on GitHub. For more information, see About writing and formatting on GitHub. Supported color modelsIn issues, pull requests, and discussions, you can call out colors within a sentence by using backticks. A supported color model within backticks will display a visualization of the color. The background color is `#ffffff` for light mode and `#000000` for dark mode.
Here are the currently supported color models.
Note
LinksYou can create an inline link by wrapping link text in brackets You can also create a Markdown hyperlink by highlighting the text and using the keyboard shortcut Command+V. If you'd like to replace the text with the link, use the keyboard shortcut Command+Shift+V.
Note GitHub automatically creates links when valid URLs are written in a comment. For more information, see Autolinked references and URLs. Section linksYou can link directly to any section that has a heading. To view the automatically generated anchor in a rendered file, hover over the section heading to expose the icon and click the icon to display the anchor in your browser.
If you need to determine the anchor for a heading in a file you are editing, you can use the following basic rules:
For more detailed information on the requirements of URI fragments, see RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, Section 3.5. The code block below demonstrates the basic rules used to generate anchors from headings in rendered content. # Example headings
## Sample Section
## This'll be a _Helpful_ Section About the Greek Letter Θ!
A heading containing characters not allowed in fragments, UTF-8 characters, two consecutive spaces between the first and second words, and formatting.
## This heading is not unique in the file
TEXT 1
## This heading is not unique in the file
TEXT 2
# Links to the example headings above
Link to the sample section: [Link Text](#sample-section).
Link to the helpful section: [Link Text](#thisll-be-a-helpful-section-about-the-greek-letter-Θ).
Link to the first non-unique section: [Link Text](#this-heading-is-not-unique-in-the-file).
Link to the second non-unique section: [Link Text](#this-heading-is-not-unique-in-the-file-1).Note If you edit a heading, or if you change the order of headings with "identical" anchors, you will also need to update any links to those headings as the anchors will change. Relative linksYou can define relative links and image paths in your rendered files to help readers navigate to other files in your repository. A relative link is a link that is relative to the current file. For example, if you have a README file in root of your repository, and you have another file in docs/CONTRIBUTING.md, the relative link to CONTRIBUTING.md in your README might look like this: GitHub will automatically transform your relative link or image path based on whatever branch you're currently on, so that the link or path always works. The path of the link will be relative to the current file. Links starting with Your link text should be on a single line. The example below will not work. [Contribution
guidelines for this project](docs/CONTRIBUTING.md)Relative links are easier for users who clone your repository. Absolute links may not work in clones of your repository - we recommend using relative links to refer to other files within your repository. Custom anchorsYou can use standard HTML anchor tags ( Note Custom anchors will not be included in the document outline/Table of Contents. You can link to a custom anchor using the value of the For example: # Section Heading
Some body text of this section.
<a name="my-custom-anchor-point"></a>
Some text I want to provide a direct link to, but which doesn't have its own heading.
(… more content…)
[A link to that custom anchor](#my-custom-anchor-point)Tip Custom anchors are not considered by the automatic naming and numbering behavior of automatic heading links. Line breaksIf you're writing in issues, pull requests, or discussions in a repository, GitHub will render a line break automatically: This example
Will span two linesHowever, if you are writing in an .md file, the example above would render on one line without a line break. To create a line break in an .md file, you will need to include one of the following:
If you leave a blank line between two lines, both .md files and Markdown in issues, pull requests, and discussions will render the two lines separated by the blank line: This example
Will have a blank line separating both linesImagesYou can display an image by adding ! and wrapping the alt text in
GitHub supports embedding images into your issues, pull requests, comments and Note When you want to display an image that is in your repository, use relative links instead of absolute links. Here are some examples for using relative links to display an image.
Note The last two relative links in the table above will work for images in a private repository only if the viewer has at least read access to the private repository that contains these images. For more information, see Relative Links. The Picture elementThe ListsYou can make an unordered list by preceding one or more lines of text with -, *, or +. - George Washington
* John Adams
+ Thomas Jefferson
To order your list, precede each line with a number. 1. James Madison
2. James Monroe
3. John Quincy Adams
Nested ListsYou can create a nested list by indenting one or more list items below another item. To create a nested list using the web editor on GitHub or a text editor that uses a monospaced font, like Visual Studio Code, you can align your list visually. Type space characters in front of your nested list item until the list marker character (- or *) lies directly below the first character of the text in the item above it. 1. First list item
- First nested list item
- Second nested list itemNote In the web-based editor, you can indent or dedent one or more lines of text by first highlighting the desired lines and then using Tab or Shift+Tab respectively.
To create a nested list in the comment editor on GitHub, which doesn't use a monospaced font, you can look at the list item immediately above the nested list and count the number of characters that appear before the content of the item. Then type that number of space characters in front of the nested list item. In this example, you could add a nested list item under the list item 100. First list item
- First nested list item
You can create multiple levels of nested lists using the same method. For example, because the first nested list item has seven characters ( 100. First list item
- First nested list item
- Second nested list item
For more examples, see the GitHub Flavored Markdown Spec. Task listsTo create a task list, preface list items with a hyphen and space followed by - [x] #739
- [ ] https://github.com/octo-org/octo-repo/issues/740
- [ ] Add delight to the experience when all tasks are complete :tada:
If a task list item description begins with a parenthesis, you'll need to escape it with \:
For more information, see About tasklists. Mentioning people and teamsYou can mention a person or team on GitHub by typing @ plus their username or team name. This will trigger a notification and bring their attention to the conversation. People will also receive a notification if you edit a comment to mention their username or team name. For more information about notifications, see About notifications. Note A person will only be notified about a mention if the person has read access to the repository and, if the repository is owned by an organization, the person is a member of the organization.
When you mention a parent team, members of its child teams also receive notifications, simplifying communication with multiple groups of people. For more information, see About organization teams. Typing an @ symbol will bring up a list of people or teams on a project. The list filters as you type, so once you find the name of the person or team you are looking for, you can use the arrow keys to select it and press either tab or enter to complete the name. For teams, enter the @organization/team-name and all members of that team will get subscribed to the conversation. You can also mention an enterprise team. Enterprise team slugs use an The autocomplete results are restricted to repository collaborators and any other participants on the thread. Referencing issues and pull requestsYou can bring up a list of suggested issues and pull requests within the repository by typing #. Type the issue or pull request number or title to filter the list, and then press either tab or enter to complete the highlighted result. For more information, see Autolinked references and URLs. Referencing external resourcesIf custom autolink references are configured for a repository, then references to external resources, like a JIRA issue or Zendesk ticket, convert into shortened links. To know which autolinks are available in your repository, contact someone with admin permissions to the repository. For more information, see Configuring autolinks to reference external resources. Uploading assetsYou can upload assets like images by dragging and dropping, selecting from a file browser, or pasting. You can upload assets to issues, pull requests, comments, and Using emojisYou can add emoji to your writing by typing
Typing : will bring up a list of suggested emoji. The list will filter as you type, so once you find the emoji you're looking for, press Tab or Enter to complete the highlighted result. For a full list of available emoji and codes, see the Emoji-Cheat-Sheet. ParagraphsYou can create a new paragraph by leaving a blank line between lines of text. FootnotesYou can add footnotes to your content by using this bracket syntax: The footnote will render like this:
Note The position of a footnote in your Markdown does not influence where the footnote will be rendered. You can write a footnote right after your reference to the footnote, and the footnote will still render at the bottom of the Markdown. Footnotes are not supported in wikis. AlertsAlerts, also sometimes known as callouts or admonitions, are a Markdown extension based on the blockquote syntax that you can use to emphasize critical information. On GitHub, they are displayed with distinctive colors and icons to indicate the significance of the content. Use alerts only when they are crucial for user success and limit them to one or two per article to prevent overloading the reader. Additionally, you should avoid placing alerts consecutively. Alerts cannot be nested within other elements. To add an alert, use a special blockquote line specifying the alert type, followed by the alert information in a standard blockquote. Five types of alerts are available: > [!NOTE]
> Useful information that users should know, even when skimming content.
> [!TIP]
> Helpful advice for doing things better or more easily.
> [!IMPORTANT]
> Key information users need to know to achieve their goal.
> [!WARNING]
> Urgent info that needs immediate user attention to avoid problems.
> [!CAUTION]
> Advises about risks or negative outcomes of certain actions.Here are the rendered alerts:
Hiding content with commentsYou can tell GitHub to hide content from the rendered Markdown by placing the content in an HTML comment. Ignoring Markdown formattingYou can tell GitHub to ignore (or escape) Markdown formatting by using \ before the Markdown character.
For more information on backslashes, see Daring Fireball's Markdown Syntax. Note The Markdown formatting will not be ignored in the title of an issue or a pull request. Disabling Markdown renderingWhen viewing a Markdown file, you can click Code at the top of the file to disable Markdown rendering and view the file's source instead.
Disabling Markdown rendering enables you to use source view features, such as line linking, which is not possible when viewing rendered Markdown files. Further reading |
[# Basic writing and formatting syntax
Create sophisticated formatting for your prose and code on GitHub with simple syntax. HeadingsTo create a heading, add one to six # symbols before your heading text. The number of # you use will determine the hierarchy level and typeface size of the heading. # A first-level heading
## A second-level heading
### A third-level heading
When you use two or more headings, GitHub automatically generates a table of contents that you can access by clicking the "Outline" menu icon within the file header. Each heading title is listed in the table of contents and you can click a title to navigate to the selected section.
Styling textYou can indicate emphasis with bold, italic, strikethrough, subscript, or superscript text in comment fields and
Quoting textYou can quote text with a >. Text that is not a quote
> Text that is a quoteQuoted text is indented with a vertical line on the left and displayed using gray type.
Note When viewing a conversation, you can automatically quote text in a comment by highlighting the text, then typing R. You can quote an entire comment by clicking , then Quote reply. For more information about keyboard shortcuts, see Keyboard shortcuts. Quoting codeYou can call out code or a command within a sentence with single backticks. The text within the backticks will not be formatted. You can also press the Command+E (Mac) or Ctrl+E (Windows/Linux) keyboard shortcut to insert the backticks for a code block within a line of Markdown. Use `git status` to list all new or modified files that haven't yet been committed.
To format code or text into its own distinct block, use triple backticks. Some basic Git commands are:
```
git status
git add
git commit
```
For more information, see Creating and highlighting code blocks. If you are frequently editing code snippets and tables, you may benefit from enabling a fixed-width font in all comment fields on GitHub. For more information, see About writing and formatting on GitHub. Supported color modelsIn issues, pull requests, and discussions, you can call out colors within a sentence by using backticks. A supported color model within backticks will display a visualization of the color. The background color is `#ffffff` for light mode and `#000000` for dark mode.
Here are the currently supported color models.
Note
LinksYou can create an inline link by wrapping link text in brackets You can also create a Markdown hyperlink by highlighting the text and using the keyboard shortcut Command+V. If you'd like to replace the text with the link, use the keyboard shortcut Command+Shift+V.
Note GitHub automatically creates links when valid URLs are written in a comment. For more information, see Autolinked references and URLs. Section linksYou can link directly to any section that has a heading. To view the automatically generated anchor in a rendered file, hover over the section heading to expose the icon and click the icon to display the anchor in your browser.
If you need to determine the anchor for a heading in a file you are editing, you can use the following basic rules:
For more detailed information on the requirements of URI fragments, see RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, Section 3.5. The code block below demonstrates the basic rules used to generate anchors from headings in rendered content. # Example headings
## Sample Section
## This'll be a _Helpful_ Section About the Greek Letter Θ!
A heading containing characters not allowed in fragments, UTF-8 characters, two consecutive spaces between the first and second words, and formatting.
## This heading is not unique in the file
TEXT 1
## This heading is not unique in the file
TEXT 2
# Links to the example headings above
Link to the sample section: [Link Text](#sample-section).
Link to the helpful section: [Link Text](#thisll-be-a-helpful-section-about-the-greek-letter-Θ).
Link to the first non-unique section: [Link Text](#this-heading-is-not-unique-in-the-file).
Link to the second non-unique section: [Link Text](#this-heading-is-not-unique-in-the-file-1).Note If you edit a heading, or if you change the order of headings with "identical" anchors, you will also need to update any links to those headings as the anchors will change. Relative linksYou can define relative links and image paths in your rendered files to help readers navigate to other files in your repository. A relative link is a link that is relative to the current file. For example, if you have a README file in root of your repository, and you have another file in docs/CONTRIBUTING.md, the relative link to CONTRIBUTING.md in your README might look like this: GitHub will automatically transform your relative link or image path based on whatever branch you're currently on, so that the link or path always works. The path of the link will be relative to the current file. Links starting with Your link text should be on a single line. The example below will not work. [Contribution
guidelines for this project](docs/CONTRIBUTING.md)Relative links are easier for users who clone your repository. Absolute links may not work in clones of your repository - we recommend using relative links to refer to other files within your repository. Custom anchorsYou can use standard HTML anchor tags ( Note Custom anchors will not be included in the document outline/Table of Contents. You can link to a custom anchor using the value of the For example: # Section Heading
Some body text of this section.
<a name="my-custom-anchor-point"></a>
Some text I want to provide a direct link to, but which doesn't have its own heading.
(… more content…)
[A link to that custom anchor](#my-custom-anchor-point)Tip Custom anchors are not considered by the automatic naming and numbering behavior of automatic heading links. Line breaksIf you're writing in issues, pull requests, or discussions in a repository, GitHub will render a line break automatically: This example
Will span two linesHowever, if you are writing in an .md file, the example above would render on one line without a line break. To create a line break in an .md file, you will need to include one of the following:
If you leave a blank line between two lines, both .md files and Markdown in issues, pull requests, and discussions will render the two lines separated by the blank line: This example
Will have a blank line separating both linesImagesYou can display an image by adding ! and wrapping the alt text in
GitHub supports embedding images into your issues, pull requests, comments and Note When you want to display an image that is in your repository, use relative links instead of absolute links. Here are some examples for using relative links to display an image.
Note The last two relative links in the table above will work for images in a private repository only if the viewer has at least read access to the private repository that contains these images. For more information, see Relative Links. The Picture elementThe ListsYou can make an unordered list by preceding one or more lines of text with -, *, or +. - George Washington
* John Adams
+ Thomas Jefferson
To order your list, precede each line with a number. 1. James Madison
2. James Monroe
3. John Quincy Adams
Nested ListsYou can create a nested list by indenting one or more list items below another item. To create a nested list using the web editor on GitHub or a text editor that uses a monospaced font, like Visual Studio Code, you can align your list visually. Type space characters in front of your nested list item until the list marker character (- or *) lies directly below the first character of the text in the item above it. 1. First list item
- First nested list item
- Second nested list itemNote In the web-based editor, you can indent or dedent one or more lines of text by first highlighting the desired lines and then using Tab or Shift+Tab respectively.
To create a nested list in the comment editor on GitHub, which doesn't use a monospaced font, you can look at the list item immediately above the nested list and count the number of characters that appear before the content of the item. Then type that number of space characters in front of the nested list item. In this example, you could add a nested list item under the list item 100. First list item
- First nested list item
You can create multiple levels of nested lists using the same method. For example, because the first nested list item has seven characters ( 100. First list item
- First nested list item
- Second nested list item
For more examples, see the GitHub Flavored Markdown Spec. Task listsTo create a task list, preface list items with a hyphen and space followed by - [x] #739
- [ ] https://github.com/octo-org/octo-repo/issues/740
- [ ] Add delight to the experience when all tasks are complete :tada:
If a task list item description begins with a parenthesis, you'll need to escape it with \:
For more information, see About tasklists. Mentioning people and teamsYou can mention a person or team on GitHub by typing @ plus their username or team name. This will trigger a notification and bring their attention to the conversation. People will also receive a notification if you edit a comment to mention their username or team name. For more information about notifications, see About notifications. Note A person will only be notified about a mention if the person has read access to the repository and, if the repository is owned by an organization, the person is a member of the organization.
When you mention a parent team, members of its child teams also receive notifications, simplifying communication with multiple groups of people. For more information, see About organization teams. Typing an @ symbol will bring up a list of people or teams on a project. The list filters as you type, so once you find the name of the person or team you are looking for, you can use the arrow keys to select it and press either tab or enter to complete the name. For teams, enter the @organization/team-name and all members of that team will get subscribed to the conversation. You can also mention an enterprise team. Enterprise team slugs use an The autocomplete results are restricted to repository collaborators and any other participants on the thread. Referencing issues and pull requestsYou can bring up a list of suggested issues and pull requests within the repository by typing #. Type the issue or pull request number or title to filter the list, and then press either tab or enter to complete the highlighted result. For more information, see Autolinked references and URLs. Referencing external resourcesIf custom autolink references are configured for a repository, then references to external resources, like a JIRA issue or Zendesk ticket, convert into shortened links. To know which autolinks are available in your repository, contact someone with admin permissions to the repository. For more information, see Configuring autolinks to reference external resources. Uploading assetsYou can upload assets like images by dragging and dropping, selecting from a file browser, or pasting. You can upload assets to issues, pull requests, comments, and Using emojisYou can add emoji to your writing by typing
Typing : will bring up a list of suggested emoji. The list will filter as you type, so once you find the emoji you're looking for, press Tab or Enter to complete the highlighted result. For a full list of available emoji and codes, see the Emoji-Cheat-Sheet. ParagraphsYou can create a new paragraph by leaving a blank line between lines of text. FootnotesYou can add footnotes to your content by using this bracket syntax: The footnote will render like this:
Note The position of a footnote in your Markdown does not influence where the footnote will be rendered. You can write a footnote right after your reference to the footnote, and the footnote will still render at the bottom of the Markdown. Footnotes are not supported in wikis. AlertsAlerts, also sometimes known as callouts or admonitions, are a Markdown extension based on the blockquote syntax that you can use to emphasize critical information. On GitHub, they are displayed with distinctive colors and icons to indicate the significance of the content. Use alerts only when they are crucial for user success and limit them to one or two per article to prevent overloading the reader. Additionally, you should avoid placing alerts consecutively. Alerts cannot be nested within other elements. To add an alert, use a special blockquote line specifying the alert type, followed by the alert information in a standard blockquote. Five types of alerts are available: > [!NOTE]
> Useful information that users should know, even when skimming content.
> [!TIP]
> Helpful advice for doing things better or more easily.
> [!IMPORTANT]
> Key information users need to know to achieve their goal.
> [!WARNING]
> Urgent info that needs immediate user attention to avoid problems.
> [!CAUTION]
> Advises about risks or negative outcomes of certain actions.Here are the rendered alerts:
Hiding content with commentsYou can tell GitHub to hide content from the rendered Markdown by placing the content in an HTML comment. Ignoring Markdown formattingYou can tell GitHub to ignore (or escape) Markdown formatting by using \ before the Markdown character.
For more information on backslashes, see Daring Fireball's Markdown Syntax. Note The Markdown formatting will not be ignored in the title of an issue or a pull request. Disabling Markdown renderingWhen viewing a Markdown file, you can click Code at the top of the file to disable Markdown rendering and view the file's source instead.
Disabling Markdown rendering enables you to use source view features, such as line linking, which is not possible when viewing rendered Markdown files. Further reading |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
New customer portal: help.github.com 🚀
The GitHub support portal has been redesigned and moved to a new home at help.github.com. It brings support, docs, learning, community, and account resources together in one place, with Copilot powered search across all of them.
What's new for you:
Visit help.github.com to try it out! Please note that we're rolling this out gradually over the next couple of weeks so you may not see the new experience right away. If you don't have access yet, the prior support.github.com site and support workflow are still intact and you will be redirected accordingly.
Feedback or suggestions for improvement? Feel free to post directly to this thread 🧵 Thank you!
All reactions