GitLabHQ and a good branching model
Migrating to Git
At work, we made the move from subversion to git as our version control tool. I used git for a few times before we migrate the whole project thanks to the git-svn bridge, and, apart from the usual headache when it comes to merging branches, I was rather convinced we would make the migration to git. To explain what branching model I was expecting to use, I dig the Internet for a good tool, hoping to migrate our so "1.0" Trac version control and issue management to a more github like one.
Founds
There is not as much tools as I first thought, I found
gitorious, which seems
to be a good tool, but it looks complicated to setup and lacks (or I
didn't find it) a good graphical representation of the branches in
the repository.
I came across gitlabhq, which is
a starting project, but promising as it aims to mimic github in many
ways. I've tried it and I must say I am very impressed, it is now
one of the tool we use internally, it is not yet a perfect tool but
it does its jobs very well. We still use our old Trac environment
with git integration to hunt down our bugs and control ticket
workflow with commit messages (blog post to come). We also use
Trac's wiki to write our internal documentation toward developpers.
GitLabHQ
Repository management
Our SVN setup was hooked to our internal LDAP for central authentication across our servers (with pam-ldap), making the move to git made this part rubbish because everything is now handled by ssh key exchange. If you've played a bit with gitosis or gitolite, you have probably seen it's not as straightforward as it seems granting a new user access to a repository. You have to clone the special administrative repository and copy public keys, edit configuration file and push this back to the server. This is a simple but potentially time-consuming operation. GitLabHQ provides a GUI allowing to add projects, users, keys.
User management
It handles granting permissions in the underlying gitolite server by using the keys the user configure. The workflow of adding a new user is simple, you go to the administrative interface of gitlab, select the "add user" link, fill in basic informations for that user (login/password/mail) and the user, until he sets up its key, has a nag message on the top inviting him to add a key. There is only a simple form to fill with the key "nickname" and the key itself and it is done. If a user changes computer or got multiple ones, he can easily add another key to its profile, there is no need to ask the git administrator to add it.Project management
It is easy to setup new projects, GitlabHQ provides a section in its GUI allowing to add a project very easily, the same procedure as the one necessary for adding a user apply : a simple form, then you can set up permission for users (read-only / push-pull, web only access...)Once a project created, you can manage it via the rich web interface GitLab offers. There is :
- an integrated issue tracker (without workflow, as simple as the one in github, an issue is open or closed),
- a "merge request" section, you can view it as pull requests in github, it allows a developper to notify a reviewer its feature is ready to be merged into another branch (allowing code review),
- a code browser with built-in comment system (with line note...),
- a network graph tool (nice graphical representation of your branches),
- a snippet mode to share code sample
- a few more features, I have to admit I have enough with what I stated above.
Difficulties
GitLabHQ is a project depending on a variety of tools, initial setup is very well explained in the wiki pages of the project, I suggest you follow the guide to install this tool, otherwise you might run into troubles.Sometimes GitLabHQ does not seems to work, it gives a 500 error, if it happens, don't forget to check the logs/production.log file for errors. There is still a few bugs, but as this project is open source, feel free to open an issue on the github page of the project and/or contribute back a patch via a pull request.
Upgrading GitLabHQ
GitLabHQ's team wants to release every month, to upgrade, simply follow these steps :#stop your server
git pull origin stable
bundle install --without development test
bundle exec rake db:migrate RAILS_ENV=production
#start your server
This should make the move to the new version, please check version
notice if there is some special steps to take.
You might want to create a local branch containing your
configuration (config/gitlab.yml), and to upgrade, simply rebase
your local config branch against the tag corresponding to the
release (please notice that with 2.2 release, this is not necessary
anymore)
Migrating from Subversion to git
The migration is very simple, and very well explained on a stackoverflow answer. Once your svn repository is imported as a git one, you can push it to GitLabHQ. To do so create a repository in GitLabHQ, and just follow the instruction given in the project page (git add origin ... git push)Branching model
We migrate to git hoping to find and setup a good and easy branching model. I think we now have something really nice :
- master : branch we merge our feature branches into, the next release branch, the one being actively tested,
- stable : branch corresponding to the production code, from which we branch when bugfixing,
- fix/$issue_number : temporary fix branch, rarely pushed to central repository, coming from stable branch, merged to stable for next hotfix release, and cherry-picked to master
- feature/$feature_name : new feature branch, coming from master, merged to master, can be pushed to central repository if the feature is big enough,
- refactor/$refactor_topic : short lived branch, coming from master, merged to master
Merging changes
Once a feature / fix / refactor is considered complete and stable by the developer(s), we use the merge request feature of GitLabHQ to trigger a manual code review, and once it satisfies our quality standard we merge it into the destination branch.
Results
In the end, you got something like this :
