Gitlab workflow

[Sven Panne]

Am Sa., 6. Juli 2019 um 19:06 Uhr schrieb Bryan Richter <b at chreekat.net>:

> [...] Rather than argue against GHC's current practices, however, I would
> like
> to understand them better. What issues led to a rebase-only workflow?
> Which expert opinions were considered? What happy stories can people
> relate? We recently switched away from a rebase-only workflow at
> $workplace, and it's already made life so much nicer for us -- so I'm
> curious what unforeseen pain we might be in for. :)


I've worked for several companies of several sizes, and from my experience
the rule is: The bigger the company, the more there is a tendency to use a
rebase-only workflow, with big/huge projects exclusively relying on
rebases, explicitly forbidding (non-fast-forward) merges. There are several
good reasons for this IMHO:

   * Clarity: Even with a single release branch, merges tend to create an
incomprehensible mess in the history. Things get totally unmanageable when
you have to support several releases in various branches. IMHO this reason
alone is enough to rule out non-fast-forward merges in bigger projects.

   * Bisecting: With merges you will have a very, very hard time bisecting
your history to find a bug (or a fix). With a linear (single release) or
tree-shaped (for several supported releases) history, this gets trivial and
can easily be automated.

   * Hash instability: Simply relying on a hash to find out if a
fix/feature is in some branch is an illusion: Sooner or later you get a
merge conflict and need to modify your commit.

   * Tool integration via IDs: For the reason stated above, you will have
some kind of bug/feature/issue/...-ID e.g. in your commit message, anyway.
This ID is then used in your issue tracker/release management tool/..., not
the hash of a commit in some branch.

Of course your mileage may vary, depending on your team and project size,
the additional tools you use, how good your CI/testing/release framework
is, etc.  GitLab's machinery may still be in it's infancy, but some kind of
bot picking/testing/committing (even reverting, if necessary) your changes
is a very common and scalable way of doing things. Or the other way round:
If you don't do this, and your project gets bigger, you have an almost 100%
guarantee that the code in your repository is broken in some way. :-}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190706/e1d35765/attachment.html>