Selecting source code repository tools

From Luis Gallego Hurtado - Not Another IT guy
Jump to: navigation, search

Some context

As part of my adventure as entrepreneur, in 2019, I came up with an idea, which could be great for a digital marketplace, so I considered to launch a Startup and develop products for validating that idea.

However, despite I had participated in many projects, it was when I started working in my own idea, when I got involved into selecting the right tool for managing it, a really source code repository tool.

The source control versioning system: Git

Regarding the source control versioning system I would use there was no doubt: Git.

After using in the past other old-fashion centralized SCMs like Source Safe, CVS and SVN, working with Git had been a great experience in the last years, mostly in UK.

I remember even having used it within a company managed source with SVN, and being one of 2 devs using GIT thanks to git-svn library, provided by GitScm. That was my first approach to Git, and it gave so much flexibility to work simultaneously with several versions of the code (tickets, issues, proofs of concepts), that enpowered me to reach another level as developer.

Next projects were started with pure Git, and I got much better in conflict resolution.

Yeah, I know there are other distributed version control systems as Mercurial. However, I have no reasons, so far, to consider other source control versioning systems apart from Git. Partially since it has become nearly a standard, but mostly since I am still learning something new about it after using it last 6 years.

The repository tool

It was time now to choose a repository tool for Git. These were my main requirements:

  • Free: I would choose a free pricing tier, at least until team didn’t reach 2 or 3 devs, so all other requirements should be offered by a free pricing tier.
  • Git support: of course, as SCM would be Git.
  • Private repositories: the code of main projects wouldn’t be public, so privacy was really a key point for me. The more private repositories were included in the free tier the better.
  • Basic issue tracker: unless in a further stage I could considering issue tracking tools like Jira, Version One or Crocagile, I needed a basic issue tracker from day zero.

In that stage, I was not focus in CI/CD support. That would be a key point a bit later, depending on hosting tools for my projects, but not in that stage.

Top 3 providers by that time where GitHub, Attlasian BitBucket and GitLab.


I was really happy with GitHub. In fact, all my personal public projects were hosted in GitHub, and experience was great.

It was also the mostly used repository tool.

However, by the time I selected the tool, much before it was acquired by Microsoft, GitHub did not offer private repositories in its free tier, and that was a red line for me.


Free GitLab’s tier provided unlimited private repositories, so it suited well my requirements.

Unfortunately, issue tracker was provided as part of workflow features, so it was not offered in free tier.

Attlasian BitBucket

BitBucket was the only tool offering unlimited private repositories and basic issue tracker in its free tier. In addition, it offered a similar wiki support to the one I had enjoyed with GitHub.

This was the only tool that fulfilled all my requirements, so BitBucket was obviously the selected one.

Bitbucket and Bitbucket Issue tracker got the job done, when I was the only one working in the projects, since I didn't actually need any board to follow progress, but later, once other collaborators joined the team, BitBucket issue tracker showed some missing agile features:

  • It lacked a Kanban board
  • It lacked scrum support.
  • Board extensions, did not offer a good user experience on sorting issues and setting priorities. In fact, they had quite a few issues related to sorting tickets.

Once my partner joined the team, a better tool was required for giving her more visibility about the current status of project.

However that is another story