1. The markdown for List`List`1 would just be List`List`1. It's a little messy, but not unbearable if you're used to reading/writing HTML. While more cumbersome than normal Markdown, this approach is also much more compatible.
2. Two different markdown format styles ('standard' and 'GFM') seven different markdown CSS themes (including a Github Markdown style) preview of markdown documents with extensions.markdown,.mdown,.mkdn,.md,.mkd,.mdwn,.mdtxt,.mdtext,.text,.txt and.Rmd.
3. . an asterisk starts an unordered list. and this is another item in the list + or you can also use the + character - or the - character To start an ordered list, write this: 1. This starts a list.with. numbers + this will show as number '2'. this will show as number '3.' Any number, +, -, or. will keep the list going.
4. Bitbucket Pipelines with Deployments lets you build, test and deploy with integrated CI/CD. Benefit from configuration as code and fast feedback loops. Secure your workflow. Know your code is secure in the Cloud with IP whitelisting and required 2-step verification. Restrict access to certain users, and control their.

Written by franleplant:Tech Lead and Software developer with a degree in Engineering. Woodworker, all things Javascript, Rust and Software Architecture.Github

Bitbucket Server uses Markdown for formatting text, as specified in CommonMark (with a few extensions). You can use Markdown in the following places: any pull request's descriptions or comments, or in README files (if they have the.md file extension).

I consider PR reviews as one of the fundamental and most importanttools developers have to collaborate. We use it daily to submit changes andto get important feedback from peers and more experienced developers.

And so, it should be targeted to software developers and not to managers.

Let’s cover some of the daily tortures of dealing with Bitbucket, whichI unfortunately need to deal with.

Copying code from the PR changes into a comment#

Hey friend, how about you implement this piece of functionality in this other way?

This common and healthy workflow is fundamentally broken in BB becauseyou cannot copy code from the body of the PR into a comment without gettinga lot more than what you clearly selected.

Are you sure you want to discard (actually not) your comments?#

Trying to click anywhere else when writing a comment like for exampleexpanding to see more code will result in an alert that statesthat your comment changes will be removed which is already super annoying.But if you even do not care about discarding your comment and you go aheadand click on discard the comment isn’t really discarded! So it is completely misleading.

This is BB not caring about the amount of time developers throw into detailedcode reviews.

What You See May Be What You Get: horrible markdown support#

Markdown is a tool aimed for technical folks, it is minimal but getsthe job done without any distractions, it is notWYSIWYG (what you see is what you get)by design and partially for simplicity.

BB takes the worse of all worlds: horrible “standard” markdown supportthat varies across places and combine it with a WYSIWYG editor.This creates really weirduse cases we will cover below.

Other technical tools, such as Github, understand how important decent markdownsupport is and they use it to empower developers.They do build visual tools on top of markdown but without combining theminto a monster broken implementation.

Let’s see some specially frustrating cases

Selecting a code block language#

Instead of using the standard ”```typescript” they include a visualSelect. Guess what, professional developers don’t need this help at all, andnewbies can search the web once and forget about this.

Think about ergonomics, with regular markdown you do everything with the keyboard,with the BB inferno you first need to type the three backward ticks and then grab themouse and select your language and then click back on the code block.

This is a really poor understanding of your user’s UX!

Smart (dumb) markdown hybrid support#

The WYSIWYGmarkdown hybrid implementation produces stuff like this

List items without an empty line#

This cannot happen in the comment textbox unless you force it to, butit can happen in the PR description textbox and it can also happen when youwrite the markdown in a regular text editor / IDE i.e. when committing codevia git, when writing the README, etc.

If you don’t leave an empty line before a list then it won’t get transformed correctly:

Performance of the text box#

I have a pretty good and modern computer but most of the timeI experience heavy lags when writing a simple text only comment in BB.

I suspect this is related to the horrible WYSIWYG implementation,which we have just heavily broken down above.

Doesn’t work on large PRs#

When a PR is a large (I know, I know, large PRs should not happen, but unfortunately sometimes they do)BB will choose either

1. consuming a lot of resources
2. not displaying the entire PR

In either case the UX ends up being bad.

In case 1. you will get a lot of RAM being consumed andmost likely the scrolling and the interaction with the pagewill be even more slow and awkward.

In case 2. you need to click file by file to inspect a PR, which isn’t better IMO.

Bitbucket Markdown Code

Bitbucket is Jira applied to git#

I’ve seen that the described behaviors tend to be crosscutting problems across the Atlassian suite, Jira has similarproblems and Confluence is horrible, they are generallyreally slow and clunky and unresponsive and text editing tends to be a pain.

Bitbucket Markdown List

Understanding your product#

PRs are one of the core use cases of BB as a product,they are what have arguably made Github the beacon that it is now.

There are a few things your PR experience needs to provide at the base level

• PR title, description and inline comments.
• Every text box needs to support plain markdown and maybe mentioning other people (tagging).
• If you want to add markdown shortcuts make them insert markdown and not actually applying style.
• Good diffing visualization (which BB does well IMO).
• It is all about the code!
• Copying code from the diff needs to work as expected.
• Markdown code blocks (code snippets) are a fundamental feature of all your text boxes.
• Either provide a really good experience inside your code blocks or do nothing.
• Your app needs to be simple, small, fast and stable in time.
• Some PRs are open for long periods of time, make sure your app is stable!.

These are one the core features a good PR UI needs to provide, if anything,these need to be the best of the best.

BB seems to have prioritized being “cute” or “pretty” (is it?) instead of being functional.

Solutions#

Bitbucket is a developer centric platform, use developer centric tools,use plain old text inputs with good markdown support, add as little as possibleon top of that, make the experience of writing comments, PR descriptions,code snippets as easy, simple and fast as possible.

Don’t leak stuff from Jira and Confluence to Bitbucket, they have differentaudience. Candle in the wind diana lyrics.

And if you have time… make sure every text input in your system has a plain textmode, where either you interpret it as good old markdown or as unformatted text, eitheris much better than what you have now.

Bitbucket Markdown Table

Closing#

Liked the content? Consider subscribing, buying me coffee or even becoming a Patreon below.

Bitbucket Markdown Image