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" <keybou...@gmail.com>
To: <git-users@googlegroups.com>
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 <philipoak...@iee.org> 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 git-users+unsubscr...@googlegroups.com.
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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to