Why I Moved My Personal Projects to GitLab
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.
- I created an organization for the project.
- I even used github.io to host documentation.
Moving to GitLab
Recently, I moved my active side projects 100% over to GitLab. Why?
- 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.
- 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.
- 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.
- Use $git fetch origin to get the branch I just created locally.
- Use $git checkout to start working on the new branch.
- Use $flutter format to fix the code.
- 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.