Thanks for posting this, I'm always interested in how to advise our users better so feel free to ask questions or disagree. BTW We're trying to keep http://doc.gitlab.com/ee/workflow/gitlab_flow.html updated with the latest learnings although it is very similar to the blog post.
Everybody is talking about GitLab these days but actually I am interested to see number of those who are ready to migrate to it for real... It still a lot of talk and little realization...
At my very large and prominent employer, we use self-hosted GitLab locally, with Gitorious and GitHub Enterprise used in some other sections of the business.
Our local GitLab setup is rather recent and isn't quite a critical part of our infrastructure just yet, but I anticipate over the next few months we'll be switching more and more over to it. I recently started on a brand new project which is currently hosted on GitLab, though it'll probably move to public GitHub after we get approval to release it under a Free Software licence.
I've been using GitLab at work for 8 months or so and we love it. It comes packed up with GitLAb-CI, which we use a lot, and Mattermost, a Slack clone. I'm hoping my boss will come to his senses and switch to Mattermost.
Been following Gitlab pretty closely. At raintank we run a fairly large open source project on Github: Grafana. We're pretty frustrated with a lot of limitations on Github.
These limitations are becoming more painful as we grow our team, and deal with more issues across more repos.
Gitlab seems to be iterating pretty quickly. Github glacially.
For us, the killer feature that Github has is the network effect. We want to make it as easy for people to contribute code/collaborate on Grafana, and Github is where all the action (developers and code) is.
I suspect that many medium/large OSS projects have the same mindset.
I understand if you don't move to GitLab yet because of the network effect. Just so you know, GitLab allows people to log in with their GitHub account.
I have used it at two companies and am setting it up for one of my own right now. It's been mature to a useful extent for years, and is no doubt virtually a drop-in replacement for Github these days.
While I continue to host public projects on Github, my key reasons to host other projects on Gitlab are privacy, security, control, and availability. Pre-commit hooks (that can reject code) are awesome.
Good to hear you're happy with your GitLab server. From GitHub we import repo's, issues, wiki's and merge requests. But not milestones as far as I know. I've created an issue for this https://gitlab.com/gitlab-org/gitlab-ce/issues/13421
I still haven't seen a better git branching model than https://gist.github.com/17twenty/6733076 (aka feature branching model). I've found this model works well for smaller apps and can scale easily with modularization and feature flags.
That is not a bad model and you'll prevent merge commits. However in GitLab flow I advocate against rebasing of commits you pushed: "However you should never rebase commits you have pushed to a remote server. Somebody can have referred to the commits or cherry-picked them. When you rebase you change the identifier (SHA1) of the commit and this is confusing. If you do that the same change will be known under multiple identifiers and this can cause much confusion. If people already reviewed your code it will be hard for them to review only the improvements you made since then if you have rebased everything into one commit." I think that "Your codebase should be clean but your history should represent what actually happened.". But if you want to use your model GitLab does support it, GitLab EE and .com allow you to rebase and merge from the web interface http://doc.gitlab.com/ee/workflow/rebase_before_merge.html
I basically use the model described in this gist and dislike the fact that our review history is basically lost when we rebase to fix the commits. Rather than "what actually happened", we prefer logical commits so that when you run `git blame`, you can see a commit that makes sense rather than "WIP". What we really want is a code review system that has _changesets_ so that we can keep our git history clean, but also have a full history of our code review. I'm really surprised that in all of these GitHub discussions, there hasn't been much raised about their insufficient code review system.
https://reviewable.io deals with changes in this way and has no problems with rebasing, even distinguishing between deltas in the branch vs the base when diffing. Only works on top of GitHub, though, sorry. (Disclosure: I'm the founder.)
Phabricator solves this problem but it does so using patches (outside of "git"). It works pretty well but there does wind up being dependency problems if code doesn't get merged quickly enough.
Yup, that's usually what I prefer to do myself anyway.
Working on teams we usually commit to '$username/$feature' branches though, to keep it reasonably clean and not potentially pollute others' namespaces. We're also not allowed to merge in our own PRs (usually, unless it's tiny) to force code reviews, which generally works out quite nicely.
