-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AMI stack: ensure pull requests / disable direct pushing #11
Comments
👍 This is a nice idea |
Thanks :) I'd like to go ahead with this on Monday, if no-one objects, so that I can get on with Tilburg. |
Monday has been and gone... Thumbs up so far (thanks!) from:
OK with you, @petermr ? |
@petermr confirmed today in person. Will put this in place ASAP. |
Am now protecting master branches for:
... done! Please re-open this issue if any problems, and/or want to extend this to other branches besides master. |
@jkbcm and @tarrow: as of this evening, after a few hours' work with me to handle some existing remotes with divergent histories, @petermr now has remotes under his namespace on GitHub for all the AMI stack modules, and will be pushing to those. Until he gets into the swing of creating feature/bugfix branches, etc, which will hopefully be in the coming weeks, his pushes may be to the master branches on those repositories. |
@petermr (and others) historically pushed directly to repositories hosted on GitHub under the Contentmine organization (e.g. https://github.com/ContentMine/svg/ ). This works fine for solo developers, but doesn't scale so well to multi-person teams. It bypasses the code review steps that are afforded by using pull requests ("PRs"), and misses out on much of the value added by code hosting services such as GitHub, GitLab, BitBucket, etc.
Now that 3-4 developers will be working intensively on the AMI stack, @petermr and I agreed last week to disable direct pushing for the AMI stack's ContentMine repositories, in favour of PRs. This will facilitate publicly-visible code review and CI, and reduce merge conflicts.
Instead, contributors to any AMI stack repo should follow The GitHub Flow, such that each developer has:
(Source.)
Ideally, PRs should be performed by a contributor other than the one responsible for the PR (e.g. I would merge @petermr's PRs; he would merge mine), to ensure scrutiny; but due to the small size of the team, developers should remain able to merge their own PRs in case time pressure is high and other team members are unavailable.
This is sometimes known as a "forking workflow". It is basically the same as the "Integration-Manager Workflow" described https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows, except with PRs in place of the "Integration Manager".
I will put this in place as @petermr and I agreed last week, unless anyone objects.
Pinging @ContentMine/administrators for feedback. If you approve, please just "+1" or "thumbs up" this post. If you disapprove, please give constructive criticism :) Thanks!
The text was updated successfully, but these errors were encountered: