The "new guy" just merged master into a release branch.

The build server started bumping versions on the release branch and build "corrupted" installers.

Another developer had to spend a whole day trying to remove all the invalid commits.

Use Gitlab and Revert merges with a simple click of a button

In this case he was supposed to merge release to master and then master to develop right?

how hard can it be to revert his commit with git? One whole day seems to be a lot of time

Advice to use git-flow in the organization to avoid such problems in the future

https://danielkummer.github.io/git-...

You are welcome :)

@ShotgunSurgeon Maybe the "other" developer that reverted that was also a new guy without any experiences

@Snob And at the end it was a fake production to teach them and the new dev who messed up first was hired to do so

*cough* *cough* branch permissions *cough* *cough*

is it his fault to not be familiar with a GIT workflow yet or yours to miss setting up propper permissions?

@cephei both imo...

@bioDan using this automated git flow vs executing commmands by yourself feels like choosing between manual or automatic car transmission :D

git reset —soft lastworkingcommit
git add .
git commit -m “revert this shit”
git push origin HEAD:release

Or for those who like to rewrite the history:
git push -f origin lastworkingcommit:release

@OdeToCode Also my first thought. Which company gives the new guy the permission to merge without an review or at all?

@luftluft probably the devs in the team who don’t know how to use Git

Wait how does merging master into release break anything?

isn't the flow master -> develop -> release -> merge back into master after release is good

So since all release is based off master and all changes are newer. Merging matter into a release changes nothing?