Hi everyone. I'm Alexander Pulido. I've been part of DailyDrip since 2016. During this time the way I deliver PRs has changed drastically. When I started, a Pull Request description was just a small description, something like: This fixes X issue or This PR includes the following features. I might even combine them: This PR contains the following features and fixes these issues.

Developers tend to write these types of PR descriptions for various reasons. Maybe they need a quick merge, or they just see the PR as a filling description tool, etc. I've seen this behavior from developers at every level, including myself. Don’t get me wrong. I'm not saying that doing a small description is a bad thing. In some cases that is all you need. However, there are other times when it's not enough. Specifically in the case of a frontend developer. Doing half-assed PRs could reduce your team productivity more than you think. That's why I want to talk about the correct way to do a PR.

Everything starts with the commits. Their text is your first line of defense. Think of this as what will appear in the logs. It always should be a clear, direct and concise text explaining what change the commit makes. There are various approaches to writing commits depending on your point of view and circumstances. For distributed teams I always recommend using present-tense, imperative-style for various reasons:

1.- Git recommends it. 2.- It is more useful when working in teams and more than one person is managing merges/deploys. 3.- It tells someone what applying the commit will do, rather than what you did (which should be in the PR, not in the commit).

image alt text

Of course, this is not universal. My opinion is that it depends on what the PR is for. If it’s a new feature, present-tense is more accurate, but when you’re doing a fix or something that isn't an optional change, other people in the project are required to either merge or rebase on it. In that case it’s better to write a journal entry which describes what changed with the update, to make it easier for others in the future to understand why a change was made. That entry is like a checkpoint in your project which makes more sense if it’s written in past-tense. It’s also better for log purposes.

image alt text

If your changes are visual, you should show them using images or gifs; this will save tons of time for the reviewers, because they’ll just have to focus on reviewing the code if you’ve already shown them the actual look of the layout/element. For new features I normally use a table showing the look of each new element.

image alt text

For changes or fixes I use a dual table comparing the before and after.

image alt text If you want to show some effect I strongly recommend usinggif. If you want to show some effect I strongly recommend usinggif.

image alt text

image alt text

image alt text image alt text

Conclusion:

Here is an example of a well-organized and visually explained Pull Request. Doing this will improve the evolutionary process of your project and help you a lot when debugging. Additionally, your teammates will have a much easier time when reviewing your code. That’s it for today, happy code!