
GitLab Flow (2014) - somecoder
https://about.gitlab.com/2014/09/29/gitlab-flow/
======
sytse
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](http://doc.gitlab.com/ee/workflow/gitlab_flow.html)
updated with the latest learnings although it is very similar to the blog
post.

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

~~~
sytse
Thanks for having me.

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

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

~~~
sytse
We love Grafana, it allowed us to make GitLab.com issues three times faster
this week [https://gitlab.com/gitlab-
com/operations/issues/42](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.

------
jonathanfoster
I still haven't seen a better git branching model than
[https://gist.github.com/17twenty/6733076](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.

~~~
sytse
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](http://doc.gitlab.com/ee/workflow/rebase_before_merge.html)

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

~~~
piotrkaminski
[https://reviewable.io](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.)

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

