How to do a full review of your repository contents on GitHub

[exa-SebastianB]

It doesn’t have to be a git to do full GitHub repository reviews

Technical reviews are a cornerstone of high quality products. That’s why we always review documents, implementation processes and tests as part of our software development process. We also invite coders around the world to contribute to the software we share with the community. Check out our Open Source repositories.

But sometimes you might find yourself in a situation where a project member wants to make a complete review of the contents of a GitHub repository. To do this, Github offers built-in review functions for pull requests. GitHub displays the contents of all changes between two branches that you can comment on – the branch that you want to merge and the branch that you merge it into.

But to do a full review, you need to see all the changes, right from the start, in one pull request. Sound complicated? Don’t worry. Here’s our step-by-step guide:

Step-by-step guide

Follow the steps below to create a full pull request review:

1. Change to the directory containing the Git repository.
2. Think of a review subject and save the name in a variable. Make sure you don’t use spaces.
   review_subject="sql-statement-builder-full"
3. Find the commit hash of the first commit in the repository
   first_commit=$(git rev-list --max-parents=0 HEAD)
4. Create a new branch from the first commit. I suggest to start with the branch name review/<review_subject> in order to easily distinguish it from regular branches.
   git branch "review/$review_subject" "$first_commit"
5. Push the branch.
   git push origin "review/$review_subject"
6. Create a new pull request on GitHub. Pull the branch that you want to be reviewed into the review branch.

   

7. Invite reviewers

Merging the results

You should work in the changes based on your reviewers' findings directly on the review branch. That way reviewers  can see the improvements. And conveniently, GitHub automatically marks previous findings as obsolete where you made changes.

When you finish the review, simply merge the review branch back to your regular integration branch. Depending on your branching strategy it’s typically called either “develop” or “master”.

And that’s it.