Why I Moved My Personal Projects to GitLab – InApps 2022

InfluxData sponsored this post.

I can’t distinctly remember the first time I used a third-party public source code repository. For the sake of argument, let’s say this code up on SourceForge I uploaded marks the event after I left Microsoft. Apparently, my first project there used CVS, but then I changed to SVN for future projects. This probably provides a good sense of the time frame in which I was working then.

Then in 2009, when I joined Canonical, we had a site called Launchpad and a related concurrent versioning tool called bzr. If you browse my repositories, you can see that I got in the habit of putting all of my code online.

Somewhere along the line, I started a GitHub account as well and I stayed in the habit of dumping my code there. After I left Canonical I also moved over all of the code that I thought was interesting. Last year, I started a side project that I got really into for a while and went all-in on using GitHub features.

1. I created an organization for the project.
2. I even used github.io to host documentation.

Moving to GitLab

Recently, I moved my active side projects 100% over to GitLab. Why?

1. I find the GitLab UI to be cleaner in general and easier to find my way around. However, this is purely a matter of taste and probably not a strong reason to move.
2. I also like how GitLab is open source. I am far from an open source zealot, but I do prefer to write and use open source software. While Github is full of Open Source projects, Github itself is proprietary. In contrast, Gitlab has a well-supported open source version.
3. The project import feature worked very well, so it was trivially easy to move the code, branches and issues over.

GitLab Workflow

Probably the most important reason is that I find their project management workflow easy to use. Let me show you a short example. I noticed that the analysis page on the project tab for my own program, Rapido, was complaining that I didn’t run $flutter format (flutter) on all of the code files. Normally, I would just fix this and push to master, but it’s an easy change to demonstrate why I use GitLab.

First, I create a new Milestone with a start and end date. This step is not required, but I like to do it because it makes it easier to create a board because you can tell the board to filter for issues in that Milestone. If I take a few minutes to add weights to each issue, it also automatically creates a burndown chart.

By default, there are no issues in the milestone, so none on the board. There are only two tasks for this project, but I will add them for demonstration purposes.

Issues are super fast to add with the “+” button.

Next, I choose a task to work on and move it to the “Doing” column by dragging it over.

This lets the world know that I am working on this item. Note that it is easy to add new columns. I added a “Blocked” column to one of my boards for a different milestone, for example.

Next, I click on the issue I am working on, I create a branch for the issue:

Next, I move over to my development computer and actually fix the issue. Normally, this would involve coding, but this particular issue I will fix with just a single command.

1. Use $git fetch origin to get the branch I just created locally.
2. Use $git checkout to start working on the new branch.
3. Use $flutter format to fix the code.
4. Push the branch.

The whole workflow looks like this:

Now I go back to GitLab, make a Merge Proposal (their name for Pull Request). And accept it. Of course in a project with collaborators, I would assign the MP to someone else to accept, but this gets the idea across.

Notice GitLab knew what issue this MP closed and it added a comment for me automatically. Because of this, when I go back to the project board, you can see that the board was updated for me automatically.

I am ignoring many of the other features integrated into GitLab, such as CI, that I plan to use in the future. In terms of reports, the burndown graph (at least that what I call it) for this particular milestone is boring, but the milestone for a bigger project was created and kept up to date automatically and is somewhat more interesting.

I love that this workflow is all integrated. I have another project where I am collaborating with a friend and I find that the GitLab workflow works very well for that.

I suppose some people will point out that I can do all of this with different combinations of GitHub features and add on products, but, I have to say, it never seemed so simple and well designed as this.

Internet Points

So, what am I giving up by moving to GitLab? So far as I can tell, mostly free internet points.

I think GitHub’s strongest pull for my personal projects is the social network. Rapido has 69 stars now, which is a modest amount of expressed interest, but it is more than the one star I myself added to the project in GitLab. Additionally, I have never heard anyone say, “this is my GitLab handle” the way people do for GitHub.

Aside from fake internet points, I have received some contributions in GitHub. So far, these have been mostly of the typo fix variety, but make no mistake: they  are useful contributions. I suspect that there is a risk people will not contribute to the project on GitLab because they do not have GitLab accounts and don’t want to learn new tools. Time will tell. I can always unarchive the project in GitHub if I decide I have made a mistake.

List of Keywords users find our article on Google: