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://gist.github.com/smyaseen/ab4ee4a159ba8071aaab6335c4d7423e ..... 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 - Create a custom template with Markdown, and name it "PULL_REQUEST_TEMPLATE.md"


Paste the following example: ## Description



## 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



## 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? Head to your GitHub repository, select the default branch, and make a .git folder at the root.


Put the template in the folder and commit changes.


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 Helloooooooo! 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://gist.github.com/smyaseen/ab4ee4a159ba8071aaab6335c4d7423e https://gist.github.com/smyaseen/ab4ee4a159ba8071aaab6335c4d7423e ..... Contents: ⚡ Wait What? ⚡ But Why? ⚡ But How? ⚡ Wait What? Wait What? ⚡ But Why? But Why? ⚡ But How? 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 - Create a custom template with Markdown, and name it "PULL_REQUEST_TEMPLATE.md" Paste the following example: Create a custom template with Markdown, and name it "PULL_REQUEST_TEMPLATE.md" Create a custom template with Markdown, and name it "PULL_REQUEST_ TEMPLATE.md " TEMPLATE.md Paste the following example: Paste the following example: ## Description



## 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



## 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? ## Description



## 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



## 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? Head to your GitHub repository, select the default branch, and make a .git folder at the root. Put the template in the folder and commit changes. Now, every time someone makes a PR, the template will appear. Head to your GitHub repository, select the default branch, and make a .git folder at the root. Head to your GitHub repository, select the default branch, and make a .git folder at the root. Put the template in the folder and commit changes. Put the template in the folder and commit changes. Now, every time someone makes a PR, the template will appear. 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 GitHub LinkedIn LinkedIn

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Too Long; Didn't Read

Download free Tech Leaders Productivity Report!

How to Elevate Your Development Workflow With GitHub PR Templates! 🌟

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Stop Wasting API Calls & Implement the Tab Leader Pattern Instead

When Value Moves Like Information: Why Developers Are Building Bitcoin Into Everyday Apps

A Guide to Effective Pull Request Reviews - Part 2

Gated-Source: Rethinking How Open Source Developers Get Paid

Python Script to Read and Judge 1,500 Legal Cases

Stop Wasting API Calls & Implement the Tab Leader Pattern Instead

When Value Moves Like Information: Why Developers Are Building Bitcoin Into Everyday Apps

A Guide to Effective Pull Request Reviews - Part 2

Gated-Source: Rethinking How Open Source Developers Get Paid

Python Script to Read and Judge 1,500 Legal Cases

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps