Hi Michael,
I think we are, in general, agreeing about direction of travel, which was my
little 'rant'. It is far too easy in larger organisations for 'management'
to create processes that give the message that 'the beatings will continue
until morale improves', which can become a vicious circle, ending up in even
more reviews before code is allowed to be tested. Usually followed by other
catch 22 scenarios such as being unable to provide more test capability
until the code is good, etc., etc., etc. This often leads to big merges of
occasional large commits all in one go (but it does self-justify the
organisation's size and purpose ;-)
As you note, there are grades of approval as code features are pushed up the
hierarchy, with ultimately a release tag signed by some high up person.
One of the areas that usually has a little bit of local control is in how
the repo servers are configured, so that there is a buffer layer of personal
server space between one's personal machine (with all the backup/archive
issues there-in) and the central server with senior staff commit authority,
and all the back-up and archive already sorted. By providing a shim layer
that feels like 'Github' or any of the other on-line 'backup/archive/public
view.private push' service, but locally within the organisation, one
'enables' the devs to get ahead of the game. Add in a CI service (for the
devs, rather than the QA system), and you greatly facilitate productivity,
and importantly release 'senior staff / management' from (allegedly) picking
up the dross and actually getting on with what they are meant to contribute
with is usually a big picture vision and overview of where it's all going
(rather than inward oversight).
Having the shim layer gets past the 'direct' in your `"trivial" setup of
every developer pulling directly from each other's branches` by always
making them properly managed remotes. The upstream also needs to have the
equivalent of git's pu to show what is being considered at that level.
<hopefully preaching to the choir just there>
You said "submits a pull request from their master to your master -- which
is as close to a "no-no" as I can imagine, I want their stuff to come in on
a branch."
- I think in this case we fall into the trap of the accidental confusion of
IIUC 'nominative determinism' (the name isn't the thing | cest ne pas une
pipe). If they simply renamed their master branch to 'feature', it doesn't
really change anything - it's the same sha1. If the merge-base is far away
then perhaps its an issue and they should have rebased first;-).
(Rhetorical) Maybe we need to have a Rose branch, which by any other name
would smell just as sweet (I wonder if a patch to change master to Rose
would be acceptable upstream ;-)
I agree that there is a lack of good discussions and reference work that
shows how to make a dev system work and why Git's approach (and implicitly
what that approach is - it's too hidden) actually works. As I said all the
old problems that CM was meant to solve are no longer problems at all (in
software dev), and the new problems are solved by new tools such as git
(which doesn't actually *control* revisions, given anyone can fork at any
time) provide Distributed Revision Authentication and Tagging (DRAT) [ooh I
like that newly invented acronym]
--
Philip
Aside: I discovered Git in 2011 when I read a blog item and immediatly saw
that it was 'the answer' to the CM nightmare that most companies impose (I'm
in engineering). Progress can be slow!
----- Original Message -----
From: "Michael" <[email protected]>
To: <[email protected]>
Sent: Friday, August 26, 2016 6:22 PM
Subject: Re: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or
something else
On 2016-08-25, at 2:44 PM, Philip Oakley <[email protected]> wrote:
Hi,
I think you should review points 1 and 2 because they try to re-inforce a
centralised control system. And then pass off the responsibility to a
machine.
Actually, I think that those points are still relevant even today:
What is important:
• pull requests: would like to kick off build based on approval of code
review
• branch permissions: we want to disable direct commit to master branch.
we do not want devA to be able to modify branch created by devB (not a
deal breaker if unavailable)
The idea that one developer is responsible for the code on a given branch is
not a bad thing; actually making someone responsible for changes to a setup,
with the ability to say "approved" or "not approved" is a good thing.
It's perfectly OK for devA to make a suggested change -- a pull request --
to devB's branch, but devB is the one that says "yea" or "nea". If DevA
still wants it done, then devA makes and owns their own branch.
There is no "Not my fault" in this approach.
Equally, the first goal of requiring code reviews and pull requests is also
a good thing.
Given that Gitb is a "distributed control" system,
Git can be a distributed system. It has all the elements needed. It does not
enforce a top-level master.
But it can still be used as a top-level master.
Most SCM's are based on "One repository serves many developers". Git is
based on "One repository serves one developer, and the repositories can
share with each other".
But there is one Linus at the top of Linux.
In any public/open coding project, there is one person that decides to
compile and release the code in project X, even if there are other people
that forked X and want to release their own version.
Someone has to say "This is good"; someone has to put their name on it.
Someone owns the repository that is considered the "master" by the people
who are going to release and support the program used by others.
It's much better if responsibility stays with the human (see the `git help
workflows` man page, `tutorials` page, user-manual and especially
https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows).
Yea, I've looked at those. They fail to adequately describe what I would
have thought was a very common behavior / my normal use case -- making a
fork of an existing project, making my changes on a branch off the old
master, and then submitting that branch as a pull request to the master. In
the process of trying to understand this, I found that "pull requests" are
actually something added by GitHub and BitBucket, and are apparently not a
git-native feature.
There also isn't a really good description of what to do when someone else
forks your code, makes changes on master, and then submits a pull request
from their master to your master -- which is as close to a "no-no" as I can
imagine, I want their stuff to come in on a branch.
I remember a really good article pointing out that the "trivial" setup of
every developer pulling directly from each other's branches and making
changes -- something that is apparently a chapter 1 or 2 concept in all git
books -- is a horrible setup that does not scale and causes all sorts of
issues. (That does not mean I could explain the problems/issues, just that I
learned not to do that). So, the lack of a good "Here's how to actually set
up a real-world, multiple-devs contributing to a given codebase that has a
central "sign-off" person -- even not even considering that there is a
central person because "Distributed for the win!", just results in lots of
people trying to re-invent the wheel with no actual learning/progress.
Git is assembly language; we are currently at a mix of fortran/cobol/basic
in it's usage. I'm not sure that people even know what is the "goto" to
avoid yet; it's certainly not clear to me. Heck, there's how many different
versions of git-flow?
---
Entertaining minecraft videos
http://YouTube.com/keybounce
--
You received this message because you are subscribed to the Google Groups
"Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
