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

Syed Muhammad Yaseen - Jul 23 - - Dev Community

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

. . . . . . . . . . .
Terabox Video Player