Elevate Your Development Workflow with GitHub PR Templates! ๐ŸŒŸ

smy

Syed Muhammad Yaseen

Posted on July 23, 2024

Elevate Your Development Workflow with GitHub PR Templates! ๐ŸŒŸ

Helloooooooo!

Hope you're doing great! This is SMY! ๐Ÿ‘‹ Let's Jump right in ๐Ÿš€

....

I've gathered and put together an Extensive PR Template! Feel free to tailor it further to align with your style.

Template Link: https://lnkd.in/djHD24pH

.....

GitHub PR Template

Contents:

  • โšก Wait What?

  • โšก But Why?

  • โšก But How?

1๏ธโƒฃ What -

PR templates offer a visual snapshot for reviewers to quickly grasp the essence and state of a pull request. Imagine your team diving into a PR and instantly comprehending its purpose, changes, and necessary actions. That's the magic of a well-structured template.

2๏ธโƒฃ Why -

Reason 1: Mind Off the Trivial, Focus on Impactful

Say goodbye to mental juggling! Templates serve as a self-checklist, eliminating the need to wrack your brain over remembering small yet crucial details. Instead, channel that mental energy towards crafting exceptional code and solving complex challenges.

Reason 2: Living Documentation

Treat your PR template as a living, breathing document that captures the essence of each change. It's not just about the present; it's a reference point for the future. Easily traceable and understandable, it becomes a valuable resource for anyone peeking into the history of your codebase.

But wait, there's more! ๐ŸŒŸ

Reason 3: Consistency & Standardization

With PR templates, maintain consistency across your project repositories. Whether you're working on bug fixes, feature enhancements, or other changes, ensure a uniform approach that aligns with your team's best practices.

Reason 4: Enhanced Communication

These templates aren't just for code; they foster better communication within your team. Express your intentions, highlight potential issues, and open the floor for meaningful discussionsโ€”all in one structured format.

Reason 5: Effortless Onboarding

Simplify onboarding for new team members by providing a clear blueprint for creating effective pull requests. It's like having a welcome mat that guides them through the team's established processes.

3๏ธโƒฃ How -

  1. Create a custom template with Markdown, and name it "PULL_REQUEST_TEMPLATE.md"

  2. Paste the following example:

## Description

<!--
Please do not leave this blank
This PR [adds/removes/fixes/replaces] the [feature/bug/etc].
-->

## What type of PR is this? (check all applicable)

- [ ] ๐Ÿ• Feature - A new feature.
- [ ] ๐Ÿ› Bug Fix - self-explanatory
- [ ] ๐Ÿ“ Documentation Update - Documentation and related changes.
- [ ] ๐ŸŽจ Style - Changes that do not affect the meaning of the code; for example, white space, formatting, or missing semicolons.
- [ ] ๐Ÿง‘โ€๐Ÿ’ป Code Refactor - A code that neither fixes a bug nor adds a feature. (eg: You can use this when there is semantic changes like renaming a variable/ function name).
- [ ] ๐Ÿ”ฅ Performance Improvements - A code change that improves performance.
- [ ] โœ… Test - Added | Modified | Removed tests
- [ ] ๐Ÿค– Build - Changes related to code building (e.g. adding npm dependencies or external libraries).
- [ ] ๐Ÿ” CI - Changes that affect the build CI/CD pipeline
- [ ] ๐Ÿ“ฆ Chore - Changes that do not affect the external user (e.g. updating the .gitignore file or .prettierrc file).
- [ ] โฉ Revert - self-explanatory

## Related Tickets & Documents

## Mobile & Desktop Screenshots/Recordings

<!-- Visual changes require screenshots -->

## Quality Checklist

- [ ] ๐Ÿ‘ทโ€โ™€๏ธ Created small PR.
- [ ] ๐Ÿ‘ด๐Ÿป No deprecated or outdated code is introduced
- [ ] ๐Ÿ’ญ Code is self-documenting. Comments are unnecessary and should only be used to explain why a decision was made
- [ ] ๐Ÿ—’๏ธ Methods are documented with JS Doc including description, params, and return type
- [ ] ๐Ÿ“‹ The commit message follows our guidelines
- [ ] ๐Ÿ‘Œ The pull request description explains any decisions or trade-offs made regarding code quality and design
- [ ] ๐Ÿ”– The branch follows our naming guidelines

## Self Checklist

- [ ] ๐Ÿ‘“ I have followed the style guidelines of this project
- [ ] ๐Ÿคณ I have performed a self-review of my code
- [ ] ๐Ÿท๏ธ I have correctly labelled PR & added Ticket Number
- [ ] ๐Ÿ™†โ€โ™‚๏ธ I have cleared the Acceptance Criteria
- [ ] โš ๏ธ My changes generate no new warnings

## Added tests?

- [ ] ๐Ÿ‘ yes, new and existing unit tests pass locally with my changes
  - [ ] โ™ป๏ธ had to make changes to existing tests
- [ ] ๐Ÿฅน no, because I need help
  - [ ] โฎ๏ธ some existing tests are failing
- [ ] โŒ› no time to add tests
- [ ] ๐Ÿ™… no, because they aren't needed

## Added to documentation?

- [ ] ๐Ÿ“œ README.md
- [ ] ๐Ÿ“ Confluence
- [ ] ๐Ÿ™… no documentation needed

## [optional] Are there any post-deployment tasks we need to perform?

## [optional] What gif best describes this PR or how it makes you feel?
Enter fullscreen mode Exit fullscreen mode
  1. Head to your GitHub repository, select the default branch and make a .git folder at the root.

  2. Put the template in the folder and commit changes.

  3. Now, every time someone makes a PR, the template will appear.

Wrapping Up:

We just Elevated Your Development Workflow with a GitHub PR Template. ๐Ÿš€

.....

Now you can supercharge your development workflow ๐Ÿš€

That's it, folks! I hope it was a good read for you. Thank you! โœจ

๐Ÿ‘‰ Follow me

GitHub

LinkedIn

๐Ÿ’– ๐Ÿ’ช ๐Ÿ™… ๐Ÿšฉ
smy
Syed Muhammad Yaseen

Posted on July 23, 2024

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related

ยฉ TheLazy.dev

About