What is the point of pull/merge requests?

Question

Is the point just to eyeball the code to check if it's "correct". How do you know if the code will actually run and not fail without accepting it and running it. (Then reverting it if it's wrong) It seems kind of convoluted. Is the testing supposed to be the responsibility of whoever initiated the pull request? Or is there some workflow to run the code before accepting it into master?

Answer 1

Many GitHub projects use Travis (or other CI) integration to run builds across all branches, including pull requests. So the pull request is just a nice git-integrated way to submit patches to a project. I see it as a "bug report with patches" option, compared to a plain "bug report".

Answer 2

1. Review code

   When working on a project you want to make sure everyone on the team knows what's going in or being removed from the code base. Also, a 2nd or 3rd...or 4th or 5th set of eyes doesn't hurt.

2. Test code

   A CI service (a la TravisCI) will run automatically to make sure nothing is broken and is the first line of defense to ensure a green master build - I can't stress this step enough.

3. Discuss code

   Should this feature/request even be a part of the code base? Is there a better way to implement it?

4. Checkpoint

   Current deploy broken? It's much easier to locate a merge commit/pull request node instead of an individual commit node.

5. Communication

   There can never be enough communication around code. Someone is always out of the loop