[luketheobscure]

When emoji use follows a strict convention (something like https://gitmoji.carloscuesta.me/), it can make it easier to scan a list of commits and get a rough idea of where the development focus is (i.e., hardening vs. feature development).

[aylmao]

I've seen this convention before. I personally find it more useful to tag commit messages with [fix], [docs], etc. It makes it more easily searchable, which is IMO what you really want. You can:

    git log --pretty=oneline --abbrev-commit | grep "\[doc"

to see documentation commits, and count them by piping to `wc`.

Emojis feel... complicated. What do they mean? Here you're just typing the literal word so not much to remember or search.

[dkarl]

Using emojis feels a bit cliquey, in-groupy. It's an extra barrier to a new developer wanting to get familiar with the project or contribute a quick fix. And you know people are going to get emojis mixed up because different associatons come to mind for different people, so project committers are going to have to be diligent about noticing and correcting mistakes. For me, the effect is the opposite of the casual and inviting atmosphere I think they're intended to create.

[dgzl]

>Emojis feel... complicated. What do they mean?

My first smartphone was a Galaxy S2, and I frequently used an emoji that looked like a character giving a sly winking-type gesture.

It took me several years to realize that this was actually the eye-rolling emoji, and every other system's implantation clearly showed this. Some of the more strange responses I received started to make sense.

[wehrkeoruw]

You can't search by arbitrary Unicode characters?

[cbsks]

It isn't unicode. I cloned the repo, this is the commit message in the command line:

  :rotating_light: Lint

Here's the same commit in GitHub: https://github.com/liyasthomas/postwoman/commit/4c9c9a224061...

Why not just use "[rotating_light] Lint" as the commit message? Or even better: "[lint] Make changes recommended by foo lint\n\nThis is the foo command used: ..."

[gatherhunterer]

That is far too much vocabulary to use effectively. A single-word designation would be much easier to discern and easier to translate. A word can be translated in a way that is meaningful but the “obvious” associations of the emojis may not make any sense in the context of a different language. Replacing language with inscrutable symbolism is bad design.

[Ayesh]

I really would like to see how Linus would react to a PR with commit messages like this.

[steve_adams_86]

I've been using the same branching strategy for about 5 years, and it has worked really well. I suspect it's fairly common, although everywhere I've worked we've switched to this from something with less structure. Essentially the branch naming pattern looks like:

    [ticket-type]/#TICKET-[ticket-description]

In practice it might look like:

    bug/APP-123-prevent-auth-redirect-loop

It makes it so you can easily automate ticket statuses with commits and merges, grep for types of issues without needing to type/remember an emoji, and you don't need to worry about emojis rendering differently on different platforms. The text will always be the same.

The emoji thing is fine if it's for fun - we should all enjoy ourselves and our work a little more - but I'm hard pressed to see the practicality of it.

[danudey]

> I'm hard pressed to see the practicality of it.

The first thing that comes to mind is that it takes up less space and is thus easier to scan. Also, people with visual impairments may have an easier time scanning based on color/shape rather than reading each individual line.

Also, it's just as easy to grep for ':bug:' than 'bug', or rather, it's more specific to do so. Likewise, people suggesting [bug] have to worry about whether their shell or grep is going to interpret the square brackets (they will).

git log | grep '[bug]' - does not do what you want

git log | grep [bug] - fails in ZSH; works as above in bash

git log | grep bug - matches lots of things, not just the tag

git log | grep ^bug - Doesn't work because 'git log' puts spaces in front of commit lines

git log | grep :bug: - Does exactly what you expect it to and nothing else.

That's the practicality that I see, personally.

> you don't need to worry about emojis rendering differently on different platforms

You don't really need to worry about that anyway, as long as you're generally on the same one or two platforms. A user on Ubuntu will always see the same bug, even if :bug: gives them a different bug illustration than an iOS user sees. In the git commits, it's represented as the tag (:bug:) and not the literal emoji.

Lastly, I fail to see anything that has to do with branching strategy with regards to emoji. This is purely commit messages and (in this case) the readme. Your branching strategy doesn't tell us anything about individual commits.

[thephyber]

> git log | grep ^bug - Doesn't work because 'git log' puts spaces in front of commit lines

No, but this does work:

    git log --grep ^bug

[eeZah7Ux]

A simple text string would be much faster to search in a browser or command line.

Most browsers would highlight all the matches.

On top of that, emojis are much less friendly to visually impaired people.

[ijustwanttovote]

Easier to glance at an emoji than a commit message. Thanks for this guide.

[ben_jones]

Emojis look different on different operating systems (and sometimes don't even render)...