DevHub: TweetDeck for GitHub

If you are spending a lot of time on GitHub, following people, teams, and projects, then checkout DevHub – a TweetDeck-like application for GitHub that works on Android, iOS, and as a web application.

It conveniently brings together your repositories, notifications, and all the other goodies, helping you to significantly cut down the time and mouse clicks.

On good commit messages

The evolution goes on.  Now that we’ve kind of sorted out most of our infrastructure, development tools, flows and processes, I guess, it’s time to look deeper into the things we’ve had for a while and reiterate over them.

Recently, I’m seeing a lot of blog posts on articles on how to write good commit messages.  Sure, we’ve had these for a while.  But lately things get a little bit more serious.

Here’s one (in Russian) that I’ve read recently.  Here’s another one (in English) that shares some of the concepts and suggestions.

What are they saying?  Well, “write better commit messages”, obviously.  But there are a couple of specific bits which I found interesting.  They are:

  • Conventional Commits – a specification for adding human and machine readable meaning to commit messages.
  • Commitizen (git cz) – a tool that help to write conventional commits.

For the skeptics among you, I slightly share your feeling.  It does seem like a bit too much overhead.  But as someone who works with an ever-growing team on a large number of projects, I think there is a place for it.  It’ll take a while to integrate, update the process, and enforce the discipline, but I think it’s well worth it.  At the very least, it deserves a try.

git merge vs. git rebase

There’s a lot of confusion between git merge and git rebase even among seasoned users of git.  “An Introduction to Git Merge and Git Rebase: What They Do and When to Use Them” is a great article explaining the pros and cons of each, and when and why using each of this is better.

While I understand it a lot better now, I still much prefer the merge approach.  It’s simpler and less dangerous, and maintains the full history.  This might get noisy at times, but works as a last resort when trying to understand what was going through the developer’s head when he was working on a piece of code.

sr.ht (“sir hat”) – open source software suite for managing your software development projects


sr.ht – pronounced “sir hat” – is a new competitor in the world of GitHub, BitBucket, and GitLab.  Much like all of these, you can either self-hosted it or use a managed service.  It might not yet be as fancy, polished, and cool (I think they need a better name and the domain) as its competitors, but there are a couple of reasons that might make a difference when making a choice:

  1. Open Source.  From a quick look, sr.ht is distributed under the GNU Afero GPL.
  2. Modular.  The suite consists of the following components:
    1. git – git repository hosting service
    2. build – continuous integration service
    3. lists – mailing lists service
    4. todo – ticketing system / bug tracker
    5. dispatch – task dispatcher and integration service
    6. man – markdown and git-based wiki service
    7. meta – account management service

 

On submitting trivial patches


Hacker News points to this Linux kernel patch, done by a 4-year old.  With some assistance, of course, but still impressive.  And while the story is cute, the comments are even better.  In particular, a link to this email from Linus Torvalds, talking about the importance of the small and trivial contributions.

To me, the biggest thing with small patches is not necessarily the patch itself. I think that much more important than the patch is the fact that people get used to the notion that they can change the kernel – not just on an intellectual level (“I understand that the GPL means that I have the right to change my kernel”), but on a more practical level (“Hey, I did that small change”).