Internal review before raising PR

Question

Background:
The GitHub belongs to the client. We have some newbies in the team, who sometimes miss basic naming convention and other coding protocols. So, if any senior wants to review internally there is no other way but to create a PR. But then this PR is visible to the client too.

Question: Is it possible we use a tool (better if GitHub has a feature) to review internally and then create a clean nice PR?

I understand PR itself means it is for review purposes, but at least after internal reviews, it would have genuine issues to look into not some trivial/obvious issues.

Answer 1

You could have a newbies branch (let's call it dev1) that is never pushed to the remote (GitHub) and a development branch (let's call it dev2) that is pushed to create PRs.

Junior developers would write to dev1.

Instead of using PRs in the review process, senior developers would compare dev1 and dev2 before merging dev1 into dev2.

Calling them dev1 and dev2 (or similar) creates a 2 step process and does not make anyone feel that they are treated as kids.

If you don't want all the messy commits along dev1 to show in the history that will ultimately be merged into dev2 (and pushed to GitHub), once you are happy with what dev1 looks like, you can use a "git reset squashing": the "Squashing" paragraph near the end of this page in the Git book gives a great example.

This is how this goes:

First you move HEAD back to the last commit you are happy with (presumably the last common commit between dev1 and dev2):

git reset --soft <hash>

Then you run:

git commit

That way you jump straight back to the final point you were happy with on dev1 from that last common commit between dev1 and dev2, "squashing" all those intermediate messy commits.

In this workflow, you can have a side by side comparison while you review dev1 (by diffing it against dev2), you hide all the mishaps that have happened during its development (you merge dev1 into dev2 only after you have created a nice clean history with git reset) and then you push dev2 to GitHub to create a PR.

At the end of the process, your client only sees the clean version with genuine issues and only has to review what matters.

Of course, this necessitates everyone in your team to have access to the project independently of GitHub (for instance, through an internal remote on a server or similar). So this option may not be practical in your particular setting.

If an internal remote is not practical, you can implement a similar workflow through a private clone on GitHub, as @choroba suggested.

Either way, the key elements are:

1. to have a branch hidden from your client (in your clone of the project itself or a fork)
2. to squash all the messy commits before submitting your PR so that your client doesn't get distracted by a messy history full of not really meaningful changes