Help with index
This commit is contained in:
Dmitriy Zaporozhets
parent
69ec189ad2
commit
2be107d0d9
11 changed files with 444 additions and 426 deletions
|
|
@ -1,129 +1,127 @@
|
|||
%h3.page_title GitLab Flavored Markdown
|
||||
.back_link
|
||||
= link_to help_path do
|
||||
← to index
|
||||
%hr
|
||||
= render layout: 'help/layout' do
|
||||
%h3.page_title GitLab Flavored Markdown
|
||||
%br
|
||||
|
||||
.row
|
||||
.span8
|
||||
%p
|
||||
For GitLab we developed something we call "GitLab Flavored Markdown" (GFM).
|
||||
It extends the standard Markdown in a few significant ways adds some useful functionality.
|
||||
|
||||
%p You can use GFM in:
|
||||
%ul
|
||||
%li commit messages
|
||||
%li comments
|
||||
%li wall posts
|
||||
%li issues
|
||||
%li merge requests
|
||||
%li milestones
|
||||
%li wiki pages
|
||||
|
||||
.span4
|
||||
.alert.alert-info
|
||||
.row
|
||||
.span8
|
||||
%p
|
||||
If you're not already familiar with Markdown, you should spend 15 minutes and go over the excellent
|
||||
%strong= link_to "Markdown Syntax Guide", "http://daringfireball.net/projects/markdown/syntax"
|
||||
at Daring Fireball.
|
||||
For GitLab we developed something we call "GitLab Flavored Markdown" (GFM).
|
||||
It extends the standard Markdown in a few significant ways adds some useful functionality.
|
||||
|
||||
.row
|
||||
.span8
|
||||
%h3 Differences from traditional Markdown
|
||||
%p You can use GFM in:
|
||||
%ul
|
||||
%li commit messages
|
||||
%li comments
|
||||
%li wall posts
|
||||
%li issues
|
||||
%li merge requests
|
||||
%li milestones
|
||||
%li wiki pages
|
||||
|
||||
%h4 Newlines
|
||||
.span4
|
||||
.alert.alert-info
|
||||
%p
|
||||
If you're not already familiar with Markdown, you should spend 15 minutes and go over the excellent
|
||||
%strong= link_to "Markdown Syntax Guide", "http://daringfireball.net/projects/markdown/syntax"
|
||||
at Daring Fireball.
|
||||
|
||||
%p
|
||||
The biggest difference that GFM introduces is in the handling of linebreaks.
|
||||
With traditional Markdown you can hard wrap paragraphs of text and they will be combined into a single paragraph. We find this to be the cause of a huge number of unintentional formatting errors.
|
||||
GFM treats newlines in paragraph-like content as real line breaks, which is probably what you intended.
|
||||
.row
|
||||
.span8
|
||||
%h3 Differences from traditional Markdown
|
||||
|
||||
%h4 Newlines
|
||||
|
||||
%p The next paragraph contains two phrases separated by a single newline character:
|
||||
%pre= "Roses are red\nViolets are blue"
|
||||
%p becomes
|
||||
= markdown "Roses are red\nViolets are blue"
|
||||
|
||||
%h4 Multiple underscores in words
|
||||
|
||||
%p
|
||||
It is not reasonable to italicize just <em>part</em> of a word, especially when you're dealing with code and names often appear with multiple underscores.
|
||||
Therefore, GFM ignores multiple underscores in words.
|
||||
|
||||
%pre= "perform_complicated_task\ndo_this_and_do_that_and_another_thing"
|
||||
%p becomes
|
||||
= markdown "perform_complicated_task\ndo_this_and_do_that_and_another_thing"
|
||||
|
||||
%h4 URL autolinking
|
||||
|
||||
%p
|
||||
GFM will autolink standard URLs you copy and paste into your text.
|
||||
So if you want to link to a URL (instead of a textual link), you can simply put the URL in verbatim and it will be turned into a link to that URL.
|
||||
|
||||
%h4 Fenced code blocks
|
||||
|
||||
%p
|
||||
Markdown converts text with four spaces at the front of each line to code blocks.
|
||||
GFM supports that, but we also support fenced blocks.
|
||||
Just wrap your code blocks in <code>```</code> and you won't need to indent manually to trigger a code block.
|
||||
|
||||
%pre= %Q{```ruby\nrequire 'redcarpet'\nmarkdown = Redcarpet.new("Hello World!")\nputs markdown.to_html\n```}
|
||||
%p becomes
|
||||
= markdown %Q{```ruby\nrequire 'redcarpet'\nmarkdown = Redcarpet.new("Hello World!")\nputs markdown.to_html\n```}
|
||||
|
||||
%h4 Emoji
|
||||
|
||||
.row
|
||||
.span8
|
||||
:ruby
|
||||
puts markdown %Q{Sometimes you want to be :cool: and add some :sparkles: to your :speech_balloon:. Well we have a :gift: for you:
|
||||
|
||||
:exclamation: You can use emoji anywhere GFM is supported. :sunglasses:
|
||||
|
||||
You can use it to point out a :bug: or warn about :monkey:patches. And if someone improves your really :snail: code, send them a :bouquet: or some :candy:. People will :heart: you for that.
|
||||
|
||||
If you are :new: to this, don't be :fearful:. You can easily join the emoji :circus_tent:. All you need to do is to :book: up on the supported codes.
|
||||
}
|
||||
|
||||
.span4
|
||||
.alert.alert-info
|
||||
%p
|
||||
Consult the
|
||||
%strong= link_to "Emoji Cheat Sheet", "http://www.emoji-cheat-sheet.com/"
|
||||
for a list of all supported emoji codes.
|
||||
The biggest difference that GFM introduces is in the handling of linebreaks.
|
||||
With traditional Markdown you can hard wrap paragraphs of text and they will be combined into a single paragraph. We find this to be the cause of a huge number of unintentional formatting errors.
|
||||
GFM treats newlines in paragraph-like content as real line breaks, which is probably what you intended.
|
||||
|
||||
.row
|
||||
.span8
|
||||
%h4 Special GitLab references
|
||||
|
||||
%p
|
||||
GFM recognizes special references.
|
||||
You can easily reference e.g. a team member, an issue or a commit within a project.
|
||||
GFM will turn that reference into a link so you can navigate between them easily.
|
||||
%p The next paragraph contains two phrases separated by a single newline character:
|
||||
%pre= "Roses are red\nViolets are blue"
|
||||
%p becomes
|
||||
= markdown "Roses are red\nViolets are blue"
|
||||
|
||||
%p GFM will recognize the following references:
|
||||
%ul
|
||||
%li
|
||||
%code @foo
|
||||
for team members
|
||||
%li
|
||||
%code #123
|
||||
for issues
|
||||
%li
|
||||
%code !123
|
||||
for merge request
|
||||
%li
|
||||
%code $123
|
||||
for snippets
|
||||
%li
|
||||
%code 1234567
|
||||
for commits
|
||||
%h4 Multiple underscores in words
|
||||
|
||||
-# this example will only be shown if the user has a project with at least one issue
|
||||
- if @project = current_user.authorized_projects.first
|
||||
- if issue = @project.issues.first
|
||||
%p For example in your #{link_to @project.name, project_path(@project)} project, writing:
|
||||
%pre= "This is related to ##{issue.id}. @#{current_user.name} is working on solving it."
|
||||
%p becomes:
|
||||
= markdown "This is related to ##{issue.id}. @#{current_user.name} is working on solving it."
|
||||
- @project = nil # Prevent this from bubbling up to page title
|
||||
%p
|
||||
It is not reasonable to italicize just <em>part</em> of a word, especially when you're dealing with code and names often appear with multiple underscores.
|
||||
Therefore, GFM ignores multiple underscores in words.
|
||||
|
||||
%pre= "perform_complicated_task\ndo_this_and_do_that_and_another_thing"
|
||||
%p becomes
|
||||
= markdown "perform_complicated_task\ndo_this_and_do_that_and_another_thing"
|
||||
|
||||
%h4 URL autolinking
|
||||
|
||||
%p
|
||||
GFM will autolink standard URLs you copy and paste into your text.
|
||||
So if you want to link to a URL (instead of a textual link), you can simply put the URL in verbatim and it will be turned into a link to that URL.
|
||||
|
||||
%h4 Fenced code blocks
|
||||
|
||||
%p
|
||||
Markdown converts text with four spaces at the front of each line to code blocks.
|
||||
GFM supports that, but we also support fenced blocks.
|
||||
Just wrap your code blocks in <code>```</code> and you won't need to indent manually to trigger a code block.
|
||||
|
||||
%pre= %Q{```ruby\nrequire 'redcarpet'\nmarkdown = Redcarpet.new("Hello World!")\nputs markdown.to_html\n```}
|
||||
%p becomes
|
||||
= markdown %Q{```ruby\nrequire 'redcarpet'\nmarkdown = Redcarpet.new("Hello World!")\nputs markdown.to_html\n```}
|
||||
|
||||
%h4 Emoji
|
||||
|
||||
.row
|
||||
.span8
|
||||
:ruby
|
||||
puts markdown %Q{Sometimes you want to be :cool: and add some :sparkles: to your :speech_balloon:. Well we have a :gift: for you:
|
||||
|
||||
:exclamation: You can use emoji anywhere GFM is supported. :sunglasses:
|
||||
|
||||
You can use it to point out a :bug: or warn about :monkey:patches. And if someone improves your really :snail: code, send them a :bouquet: or some :candy:. People will :heart: you for that.
|
||||
|
||||
If you are :new: to this, don't be :fearful:. You can easily join the emoji :circus_tent:. All you need to do is to :book: up on the supported codes.
|
||||
}
|
||||
|
||||
.span4
|
||||
.alert.alert-info
|
||||
%p
|
||||
Consult the
|
||||
%strong= link_to "Emoji Cheat Sheet", "http://www.emoji-cheat-sheet.com/"
|
||||
for a list of all supported emoji codes.
|
||||
|
||||
.row
|
||||
.span8
|
||||
%h4 Special GitLab references
|
||||
|
||||
%p
|
||||
GFM recognizes special references.
|
||||
You can easily reference e.g. a team member, an issue or a commit within a project.
|
||||
GFM will turn that reference into a link so you can navigate between them easily.
|
||||
|
||||
%p GFM will recognize the following references:
|
||||
%ul
|
||||
%li
|
||||
%code @foo
|
||||
for team members
|
||||
%li
|
||||
%code #123
|
||||
for issues
|
||||
%li
|
||||
%code !123
|
||||
for merge request
|
||||
%li
|
||||
%code $123
|
||||
for snippets
|
||||
%li
|
||||
%code 1234567
|
||||
for commits
|
||||
|
||||
-# this example will only be shown if the user has a project with at least one issue
|
||||
- if @project = current_user.authorized_projects.first
|
||||
- if issue = @project.issues.first
|
||||
%p For example in your #{link_to @project.name, project_path(@project)} project, writing:
|
||||
%pre= "This is related to ##{issue.id}. @#{current_user.name} is working on solving it."
|
||||
%p becomes:
|
||||
= markdown "This is related to ##{issue.id}. @#{current_user.name} is working on solving it."
|
||||
- @project = nil # Prevent this from bubbling up to page title
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue