GitLab Flow (2014)

https://about.gitlab.com/2014/09/29/gitlab-flow/

by somecoder • 10 years ago

115 22 10 years ago

about.gitlab.com

sytse6• 10 years ago

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.

JBReefer• 10 years ago

Yo thanks for being so active here and answering questions so helpfully

sytse6• 10 years ago

Thanks for having me.

jonathanfoster• 10 years ago

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.

sytse6• 10 years ago

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

jzelinskie• 10 years ago

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.

zer01• 10 years ago

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.

Philipp__• 10 years ago

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...

dijit• 10 years ago

I don't know, I moved everything I host off to my own instance of gitlab.

https://git.drk.sc/

You can still login with github or bitbucket, and there is a 'migrate project from ["github","bitbucket"], so, why not?

it even moves your issues over and such.

I did lose milstones on a few of my projects (where I used them) though.

sytse6• 10 years ago

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

DrRobinson• 10 years ago

At work we've been using self hosted Gitlab for more than a year and it works really great. Easy to use and maintain, would highly recommend.

mpswardle• 10 years ago

We're planning on migrating a single repo to Gitlab hosted this weekend to try it out.

I'm hoping this can reduce some cost since i'm currently spending a lot on Github and Travis CI.

sytse6• 10 years ago

Cool that you'll give us a try. We're working to introduce mostly free CI Runners to GitLab.com. We already have a bunch but we're working on autoscaling them so there is less wait https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/...

ajdlinux• 10 years ago

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.

nullified-vga• 10 years ago

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.

nopzor• 10 years ago

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.

sytse6• 10 years ago

We love Grafana, it allowed us to make GitLab.com issues three times faster this week https://gitlab.com/gitlab-com/operations/issues/42

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.

radlad• 10 years ago

Even as a small OSS project, this is a problem for me. I've setup a mirror to Gitlab, but I'm keeping issues / milestones / etc. on Github still.

It's arguably even harder for small projects to switch to Gitlab -- Github is the main way people discover us. That's where people are looking.

lerpa• 10 years ago

Been using the CE for more than a year. Works great.

contingencies• 10 years ago

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.

GitLab Flow (2014)

Related Stories