Open Source

When to use GitHub, when to use BitBucket

This is always a bit of a hot topic, especially amongst teams just getting ready to start properly managing their code through remote repositories.

Disclaimer: I’m only going to talk about GitHub and BitBucket in this article. If your code is your bread and butter, your only offering; you probably should consider hosting your repositories yourself. I’m also sticking with these two as they’re the most widely adopted.

When should I use GitHub?

GitHub can be found at – shameless plug, my user on there is @johnothecoder

Short answer: For anything/everything open source, or where you’d hope for community feedback and maybe even code contributions.

Personally, anything Open Source I think massively benefits from being on GitHub; it’s much more community orientated and you can host as many open/public repositories as you like.

It has some really handy graphs and charts about activity on your repository, and most developers who have anything to do with anything open source will have a GitHub account. On occasion I’ve even been contacted by recruitment agents who have found me through my GitHub, which is kind of cool.

The community on GitHub can be really helpful (though as with all things online there’s always a risk of being flamed) and GitHub, because of its huge market share has ready made integrations, if you’re looking to integrate something into your repository GitHub will almost definitely have it.

When should I use BitBucket?

Short answer: For professional development teams or closed source development

Bitbucket can be found at

I personally find that, especially for new or small development teams, BitBucket is great. You also get unlimited free private repositories, pricing is instead based on the amount of seats you need (that is, developers on your team who need access to the repository).

So for a professional development team I would always recommend BitBucket, it has all of the features you need – and comes with one very handy thing, which in a professional context gives it, I think, the edge on GitHub: Jira.

Jira is probably, in my experience anyway, the most widely adopted tool for managing development of software. It has a whole host of awesome features, which I’m not going to bang on about as, frankly, they sell it well enough themselves on their website.

However, as most project managers, digital managers, development managers and developers have all used Jira the ready made integration really comes in handy. Those integrations, which will also support you if you make the decision to move into agile, are really handy for growing teams.


When it comes to both of these tools (GitHub and BitBucket) they share a lot of handy functionality, which is one of the reasons I’ve never particularly wanted to stray (GitLab can be hosted on your own server and comes with these functionalities too); these features include bug/issue management, wiki, Packagist integration and various other things.

Realistically they’re no better or worse than one another – GitHub comes with integration into Basecamp as standard so that could be handy for digital agencies. Realistically, they will both serve you very well.






Setting up Private Packagist & BitBucket or GitHub

Hi all

This is a really quick tutorial, because frustratingly I couldn’t find one that offered me this quick guide that had an integrated approach to doing this.

I’m going to mostly cover the bits that I had to learn myself through Googling etc. in the hope that you won’t have to waste hours on Stack Overflow and so on trying to figure out how to get it working.

I’ve used composer a million times, but always as a consumer, not as a publisher. Least of all as a publisher on private packages.

This tutorial makes a couple of assumptions:

  1. You understand what Composer is and how it works
  2. You manage some private repositories and you’re dealing with private packagist for closed source code
  3. You have a basic understanding of what an SSH key is and how to generate one

Step #1 – Get signed up for a account

The first thing you will need to do, if you’re using private packagist for your packages, is sign up for an account on this will allow you to privately package your code using the usual composer method.

Don’t get confused between (which is free and for open source stuff) and which is private, and is paid for. Though you do get a free trial which is handy.

Step #2 – Allow access to your organisation/repository

Okay, this is the bit that annoyed me the most I think. BitBucket allow you to do stuff with organisation and app access and stuff.

Both BitBucket and GitHub allow you to grant access to private repositories via an SSH key. Private Packagist provide you with their SSH key, give this key access so that Packagist can access the repository to get the information from your composer.json file.

Step #3 – Generate an SSH key for your machine or server

I’m not going to explain how to do this. A quick google will reveal this, it’s well documented.

Step #4 – The gotcha, what to do with your SSH key

This is the bit that caused me some errors and got quite annoying. I usually use my various accounts to do my pulls, checkouts, etc. so I’ve not used my SSH key with my repositories.

Your SSH key must be allowed on both Packagist and your chosen repository provider (BitBucket or GitHub, usually).

What happens is, you fire off your Composer command. This goes to using your SSH key and will get the information it needs about the package, then it goes off to your repository to get the appropriate code. If you enable on Packagist and not your repository the require/install will fail. If you enable it on your repository and not on Packagist, it’ll tell you that your package wasn’t found.

Step #5 – Minimum Stability

This one is well documented, but still frustratingly buried within a pile of other documentation. There are a whole heap of tags and stuff that you can use, but ultimately the stability of a package is determined from the repository itself.

Learn about how Composer works with your repository here.

Let’s assume you couldn’t be bothered to read that, you just want a quick way to test that this is set up properly. Add a tag of v1.0.0 or whatever version number you’re using. It will assume this is a release and is consequently stable.


It’s actually remarkably easy getting this running. It’s just frustrating if, at the time like myself, you don’t know what you’re doing when it comes to creating packages, let alone managing closed source stuff through it.

Once it is running, however, it becomes beautiful. It’s a very elegant of managing dependencies, and keeping multiple sets of source code up to date. And for a very small price tag of about €14 per seat, per month; it’s definitely a cost saver. (Plus whatever you spend on repository hosting as well, of course).

I realise there are plenty of ways of hosting your repositories yourself, and of hosting your packages yourself too. This approach is more suited to companies whose development teams are too busy to want to manage this infrastructure; it’s, obviously, up to you to determine whether there’s enough value in managing this in-house, or whether it makes more sense, commercially, to pay a really small fee and not have to worry about it.