Here's something I want to try in the near future, and it's entirely inspired by Phabricator.
I won't allow the creation of "fix" or "feature branches" or personal dev branches in the "origin" remote repository. That is something the devs should keep on their local machine(s). If they must keep two machines in sync with each other then they can reference each other as Git remotes, or use a Raspberry PI or network storage in the middle. That's easy to set up using git. But pushing those non-standard / non-approved branches to origin would be rejected by Phabricator.
Essentially the Phabricator-controlled repo would only allow one or two main branches (e.g. master and develop, something that is latest stable and the other with latest reviewed changes).
Phabricator encourages to use a strict code review process using a tool called "Differential". Only reviewed and approved changes are merged as a squash-commit into the main development branch. It's a bit radical, because it gets rid of in-between commit history... but maybe it also makes the overall commit history more readable, since each code review should have a meaningful description, test plan, assigned reviewers etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Here's something I want to try in the near future, and it's entirely inspired by Phabricator.
I won't allow the creation of "fix" or "feature branches" or personal dev branches in the "origin" remote repository. That is something the devs should keep on their local machine(s). If they must keep two machines in sync with each other then they can reference each other as Git remotes, or use a Raspberry PI or network storage in the middle. That's easy to set up using git. But pushing those non-standard / non-approved branches to origin would be rejected by Phabricator.
Essentially the Phabricator-controlled repo would only allow one or two main branches (e.g. master and develop, something that is latest stable and the other with latest reviewed changes).
Phabricator encourages to use a strict code review process using a tool called "Differential". Only reviewed and approved changes are merged as a squash-commit into the main development branch. It's a bit radical, because it gets rid of in-between commit history... but maybe it also makes the overall commit history more readable, since each code review should have a meaningful description, test plan, assigned reviewers etc.