Top tips to write the perfect pull request  
Tags: showdev
Published: 2017-10-23 22:35:50

---
title: Top tips to write the perfect pull request  
published: true
description: A short guide to help improve your PR description writing 
tags: showDev
---

#What is a pull request?
If you work in a smaller team or for an organisation that doesn't use [Git](https://en.wikipedia.org/wiki/Git) then you may not be familiar with a pull request (PR). In short its a brief description of the changes you wish to add to a shared codebase, you are trying to give as much context to the changes as possible to help the development team review your code.

#First point of contact - The Title
This is the first thing any developer will read, use it to set the context of your changes and why they are necessary. Keep it short but describe exactly whats happening.

**Bad**
![alt text](https://thepracticaldev.s3.amazonaws.com/i/blkj7pkivrf7iyw4k1jp.png "Updates to the vc")
**Better**
![alt text](https://thepracticaldev.s3.amazonaws.com/i/37kb4zfv07e63ug4w5q6.png "Text updates to the view controller")
**Good**
![alt text](https://thepracticaldev.s3.amazonaws.com/i/tnsuuwhjeyohblp02ppf.png "Updating the `MainViewController` description text")


#Clarity is key
The sole purpose of the description you write is to aid the developers reviewing your changes, include as much detail as possible about the updates made. Both as a high level user interface description and also a detailed explanation of any parts of the code changes that may be hard for others to understand. 

#What to include
1. **A link to feature specification** - Generally new features are defined in a format that is linkable to your PR, including this link will allow reviewers to get the full context of the changes made.

2. **A brief summary of the feature spec** - If you have made a small change then help out the developers by saving them a click, summarise the changes requested in the PR description. Include the link as well just in case.

3. **The approach you have taken and why** - Did you implement your description text using a recursive heuristic algorithm rather than a simple hard coded string? You better explain your reasoning why. 

4. **Risk and Areas of concern** - Are you not quite sure if the code you have changed will have repercussions elsewhere in the codebase? Its always best to raise this as soon as possible maybe Dave the team rockstar will know more.

#Formatting is king
In the land of good PRs the pretty ones always win. As a general statement [Markdown](https://en.wikipedia.org/wiki/Markdown) is used to format PR descriptions in the main players of Git hosting. Make use of lists, titles, sub-titles, and links. If its easy to read you will be more likely to get a review of your changes. 

#Images and Gifs
If an image says a thousand words then a Gif says a million. Of course we would say that being associated with a screen recording application on macOS and to be fair images are good for showing static changes to the UI. But if you want to give the full context of a substantial change then a Gif is the way to go, it will set your PRs ahead of the pack and really help the developers see whats happening without running the changes themselves. 

##Gifable
Gifable is a super-simple screen recording tool that makes GIFs for you in seconds. Record the changes you have made and upload the `.gif` file to your PR description as an image link. 

![alt text](https://thepracticaldev.s3.amazonaws.com/i/3tdjln90vxk4s8o1h3xq.gif "Gif of a ascii train driving across the terminal screen")

We hope this blog was helpful, try out the app if you feel it would be useful and happy coding!

[Gifable Download (MacOS only)](https://goo.gl/nEu63Q)
[Gifable.co.uk](https://goo.gl/BSe3ea)
[Twitter](https://twitter.com/gifableApp)