First of all, congratulations! You have come this far. Creating pull requests is the last step to propose your code to the code owners as well as other contributors. It is really important to have a great pull request as it would help the reviewers to understand and learn from your delivered code better. This article will show you how to make Pull Requests great again just in 5 steps. 1. Branch Branching means you diverge from the main line of development and continue to do work without messing with that main line. The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. — . Git document A new branch should be created from the latest code of its destination branch from upstream. This means, at the point of branching, the local branch’s commit must be the same with the upstream branch’s commit. It will help to make the history of commits in the upcoming PR clean. In order to do it, if you are using Git command, you could follow these steps: HEAD HEAD git fetch --all #1
git checkout upstream/dev #2
git checkout -b Feature/New #3 #1 to fetch all the latest code from your remote repos. #2 to check out the latest code of development branch on upstream. #3 to create a new branch named Feature/New from the latest code of development branch. You also can use and apply the similar steps above to achieve the same thing. SourceTree About naming you mostly see master, release, or development as a common name for a branch. However, for refactor branches, new feature branches, or bugfix branches, what will you name? , I would love to suggest 2 ways that you could choose up to your preference. ● Ticket number or issue number-based names Let’s say you are working on a Jira ticket VAJ-96, to fix a bug in Home Screen. Then you can just name the new branch as VAJ-96/Fix In Screen _Bug_ _Home_ As one ticket might require multiple branches to complete, this naming convention can also be applied. Like these VAJ-96/Fix 1 Home_Screen
VAJ-96/Fix 2 Home_Screen
VAJ-96/Fix 3 Home_Screen _Bug_ _In_ _Bug_ _In_ _Bug_ _In_ ● Branch type based names In the development cycle, there are at least 3 branch types including Feature, Fix, and Refactor you will be working on. We can categorize our branches based on it just like these Feature/Pet_Dating
Feature/Music Pet Fix/Loading_Issue
Fix/Crash Home_Screen Refactor/Duplicated_Code
Refactor/Module_A _For_ #or _In_ #or One of the benefits you will see clearly if you are using Terminal is to use the auto-completion feature. If you are using SourceTree, this is how it looks like We can easily categorize the branch following the convention. 2. Commit In order to have a great pull request, we need to have a great list of commits. Therefore, it is important how we define a great commit. ● Commit’s content A commit should only contain what it needs. It is better to commit whenever you get something done regularly. It would help you in case you need to revert some of the commits or cherry-pick any commit to other branches as well. Don’t wait until everything is done to commit, neither to commit every line of code you write. For the honor of being an engineer, do it right! ● Commit’s name Have you ever seen a commit like “this is a commit” or “fix todo”, or “I don’t know what I am doing”? Sounds funny, but it happens every day. Honestly, it would become a nightmare in the future if you or your teammates looked back for something. For that reason, commit’s name should tell the changes itself, it might look like these Fix: - Fixed the crash on Home Screen.
Feature: - Implemented playground game view.
Merge: - Merged latest develop to the feature branch.
Chore: - Increased the build number on Production configuration.
Refactor: - Replaced Singleton pattern by Dependencies Injection. Let’s keep the message short but explicit. It might save your life one day! Last but not least, a pull request will not be great if the code within is not clean nor correct. Therefore, it is super important to make sure that the code you wrote is clean, well structured, optimal and follow your (organization’s) conventions. My recommendation here is to act as a reviewer and review the changes by yourself one last time before creating the pull request at step 3. If there is anything you think could be better, make it better! It is to make sure that the code you are requesting others to review is at your best. Hence, it would help to save you as well as other reviewers a lot of time later. 3. Propose A great pull request should have a clear name, following with detail descriptions and additional tags or labels. An example of one of my great pull requests. ● Pull request’s name The pull request’s name should tell the changes itself generally, to give an overview idea of what the pull request is about. Well, it can just follow the commit naming standard that we have seen above. ● Pull request’s descriptions The description helps the reviewers to understand better about motivations behind the code, achievements, and contributor’s explanations. — Which tickets/issues/proposals you are working on? — What have you done? — What the reviewers should know? WHY WHAT HOW I am attaching the template here so that you can just download and put it in your source repo. It will automatically fill the default description for the next pull requests. Please pass the requirement information link which are related to this PR here Please list down what you have done here Please list down what you have done here Please list down what you have done here Please highlight what reviewers should know when reviewing this PR
For example, your new proposal algorithm, your new proposal architecture
Or, show the gif to demo of how the screen you implemented works ### Jira ticket: (or Issue number, or Proposal number) ### What has changed: 1. 2. 3. ### What reviewers should know: A pull request template that you can download to use directly. ● Tags, Labels Sometimes you want to add more information for the pull request so that we can have a better filter and overview. This is an optional step. An example of one of my great pull requests.4. Review A great pull request should have responsive interactions among reviewers and contributors. The reviewers might or might not give you feedback on the code before they approve. In the case they do, it is important to make sure that you understand the feedback correctly before making any changes. Conflicts might happen at this point as people may have different approaches. So, if you think the code is perfectly right or your solution is better, debate respectfully and explain it to the reviewers calmly. Otherwise, don’t you hesitate to modify your code then commit new changes, it’s totally fine. On another side, if you are the reviewer, my advice is to focus on the code, not the person. Do it professionally and frequently, it will really help you as well as others. Don’t you spend too much time to debate or even make it personal. At the end of the day, we are one team trying to contribute to make the world a better place, not to fight, right? Photo by on jesse orrico Unsplash 5. Approve, Merge After resolving all the change requests and getting the approvals, you now can merge your pull requests to the destination branch. There are multiple strategies to merge pull requests. However, two of the most common strategies I’m using are creating a merge commit on top of the commits in the pull request and squashing all the commits in the pull request into just one merge commit. Shortly, the first strategy is mainly to merge a big feature or a refactor branch into a destination branch, to keep the history of commits. The second strategy doesn’t care about the history of commits in the pull request. It will squash all of the commits then create a new one to make the history simpler and cleaner. Therefore, it’s mostly for a small feature or a quick bugfix branch. It is now up to you and your branching model to decide either to delete the original branch or to keep it for future references. Anyway, sit back and relax. Merged?! Congratulations to get your task done. Take a break and get to a new task! Thank you for reading. I do hope you enjoy the article and please feel free to let me know your thoughts on these steps.

Fetch

Super

Daily Standup Meeting Is Wasting Your Time

Read my articles!

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Create A Great Pull Request In Just 5 Steps [A How To Guide]

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Daily Standup Meeting Is Wasting Your Time

8 underrated Git commands every programmer should know (not the usual pull, push, add, commit)

A Comprehensive Guide to the Difference Between Git vs GitHub

A Guide for Beginner Programmer on Using Git in a Team

Cherry-picking Your Teammate's Locally Uncommitted Changes in Git

Daily Standup Meeting Is Wasting Your Time

8 underrated Git commands every programmer should know (not the usual pull, push, add, commit)

A Comprehensive Guide to the Difference Between Git vs GitHub

A Guide for Beginner Programmer on Using Git in a Team

Cherry-picking Your Teammate's Locally Uncommitted Changes in Git

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps