Found the offender 😂

@DLMousey

@DLMousey haha 😂 fucking do it.. 🤣

@IncompetentDev 😂😂😂

Well offender has a fucking point! Pull request = Code ready for review, only delay for merging would be fix something or follow coding style ...etc

But who the fuck opens a pull request when the task is not yet complete, this confuses and makes things not organized.

I myself would react the same as offender, don't open a pull request until your code is ready to be reviewed!

@MrCSharp excuse me?

@gitpush i absolutely agree. why open a pull request when it's not ready yet. although my reason was to get early reviews on some of the work, anyway, still, in any case, nevertheless - WHY MERGE THE FUKIN PULL REQUEST WITHOUT ANY APPROVALS

@MrCSharp Okay. I agree, although my motive was to get early reviews for the part of the work that I've finished and just to let them know my plans, yes why open a pull request if it wasn't ready yet. But how about this:

1. I didn't even add her as a reviewer.

2. WHY WOULD YOU MERGE EVEN IF THERE WERE 0 APPROVALS

3. BITCH ANSWER ME

4. ANSWER ME

5. NO ONE TICKED APPROVE AND YOU MERGED

6. That's not her. 100% sure.

A pull request, you can just ignore especially if YOU WEREN'T ADDED AS A FREAKIGN REVIEWER

But to merge OUT OF THE BLUE even if you DON'T BELONG IN THE PR and then COMPLAIN THAT IT HAS CONFLICTS

I do have a problem with that.

@incompetentDev aaah good point tbh in that case, tho u know better, I'd ask to review commits rather than a pull request. But yes why merging before reviewing.....

@DLMousey do it

i double dare you

HIT ME AND FREE ME OF THIS MONKEY CIRCUS

@DLMousey Yeah I know XD no harm done!

I have a reason: Tests are too slow to run locally, and our CI/CD solution only tests PR'ed branches.

Also, in some cases I like people to review & comment on parts of a PR before the whole feature is ready.

@bittersweet #relatable

@incompetentDev

We do have a rule "you are allowed to ignore PRs for which the tests fail", and failing branches can not deploy anyway.

I often add a test like this->expectTrue(false, "Remember to fix the documentcontroller") just to block a branch from being accidentally deployed.

It's not optimal, and I wish github PRs were a bit more flexible in review management. Code ownership and assigning reviewers to parts of a branch is a bitch, just like QA approval on containerized staged deploys. I still want to write some apps/bots to manage it better, but haven't had time yet.

Haha dR spoiled it

Pssst.. Pull Requests are better to open when you start working on the feature and not when it is done. It is recommended way to let others know what you are working on. You can always request for review when you are done... Just sayin...

@gitpush "WIP" pull requests are a great place to discuss a feature while it's being implemented, it is much better than an issue because it can have a branch directly related to itself. Plus the developer gets the benefit of the project's official CI pipeline to review the code as it is being developed. Tons of larger projects/orgs do it this way, the one example I can remember is rust-lang, but there are many others for sure.

@tokumei @htlr

I think the main issue is that platforms with a PR functionality don't fully model the CI/CD pipeline as required by the developers and the company.

Usually you don't just need a simple "PR + review + merge to production".

You need "phased" reviews, where for example the branch first might receive a bunch of TDD tests. Maybe a senior writes a few complex migrations or sets up some architectural scaffolding. Then a junior writes some code, asks a bunch of questions, a frontend guy adds a commit with some styling sauce.

Then it passes automated unit tests & style checks, gets reviewed again by a senior for architecture issues... Then you might want to deploy the branch to a server for a QA & stakeholder review, and finally it might get merged into master.

Gitlab gets closest to a configurable step-wise "pipeline of humans" like that, but even their features are far from complete.