Hi, Given that Gitb is a "distributed control" system, 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.
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). Ideally you should be enabling the devs so that they can build and test their code automatically without needing special permissions (i.e. pre-review). This then should mean that the devs bring better working tested code to the reviews. All the old style config management approaches(*) are simply a statement of failure to appreciate the world has moved on. We now have perfect instant replication. Config management was about protecting the one and only irreplaceable master copy (Picasso, Dali, Titanic's ship plans, whatever). Now it is about verifying that you have the right copy (as given by the sha1 in Git). It is a hard lesson to unlearn. <steps off high horse> regards Philip (*) all the old CM practices are based on Drawing office practices from the late 19th / early 20th century when the Titanic was young and it was 'the master drawing' that was king and had to be protected. Coputing has completely and utterly undermined the basis for those rules. ----- Original Message ----- From: AutoKhan To: Git for human beings Sent: Thursday, August 25, 2016 6:11 PM Subject: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or something else Hello everyone, I am doing a comparison of the above mentioned servers for on-prem deployment. I would appreciate any feedback. With any of these tools, we will be using Git not Mercurial. Gitlab Community vs Bitbucket vs Gitlab Enterprise OR if another system is better than these What is important: 1.. pull requests: would like to kick off build based on approval of code review 2.. 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) 3.. conditions: merge to master will only be allowed once code review has passed This means another user/dev/tester has OK'd the pull request. Or another mechanism for this function. 4.. Nice UI 5.. multi-site HA Thanks -- 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.
