This content originally appeared on HackerNoon and was authored by Syed Muhammad Yaseen
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 "PULLREQUESTTEMPLATE.md"
\
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?
\
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
This content originally appeared on HackerNoon and was authored by Syed Muhammad Yaseen
Syed Muhammad Yaseen | Sciencx (2024-07-23T23:46:31+00:00) How to Elevate Your Development Workflow With GitHub PR Templates! 🌟. Retrieved from https://www.scien.cx/2024/07/23/how-to-elevate-your-development-workflow-with-github-pr-templates-%f0%9f%8c%9f/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.