What's your best practice: PRs or committing straight to main?

At one time, it looked like the use of pull requests was the emerging best practice, but lately I’ve been hearing other opinions, particularly from proponents of mob programming.

What do you consider the best practice? (And is that different from what you actually do today?)

1 Like

I’m not sure what the question is actually. Personally I dislike the git induced workflow of fork, clone a repo (sometimes a huge repo history to clone with useless binary artifacts), create a branch, commit changes in the branch, rebase with latest main, push the branch and then create a Pull Request to be reviewed, then merge.

I would be fine with just having the diff reviewed like would be done with Perforce or subversion. Your local, naturally shallow copy of the repo or main branch is just the main branch or just the files you want to work with, you make your changes then send that as a diff/patch to be reviewed against the latest main. Instead of branches you have small (no heavy history stored locally) copies of the directories allowing you to switch context without having to remember to run git add, git commit commands in order to switch contexts.

But overall yes, always have a review done with a CI pipeline to run the unittests and tools such as sonar before merging to main. A dedicated branch or fork with a Pull Request, is the git way to do that, but that’s git overhead.

3 Likes

I prefer to work directly with main and commit to main. I only use branches for things like testing preview version which are not production ready. Never use pull requests.

3 Likes

Hi!

  • In the company I work for we mainly use short-lived merge-requests (GitLab/GitLab-CI).
  • Dependency management is done via renovate and in most projects we just merge automatically when the pipeline succeeds.
  • The main benefit is, that both the unit and integration tests run in parallel in our worker farm. Some of these tests run up to 20 minutes and there are 15 jobs in parallel.
  • Doing this on a workstation would mostly be impossible.
  • We nonetheless do pair or mob programming a lot depending on the complexity of the task a couple of times per week. But even when mob-programming we develop in a branch and create a MR at the end which is then just set to merge-when-pipeline-succeeds, no “formal” approvals are needed.

Best Regards
Mirko

1 Like

How do you use it directly if production isn’t ready?

1 Like

Here we use Github flow all the way (forks, branches and PRs for integrating on the master/main branch).

1 Like