Remember
In a team we all work together sharing the same objectives.
This means to not commit things that are not supposed to be seen, or should not be seen, by our teammates or superiors. This includes angry comments, temporal files, irrelevant code, keys and passwords, etc.
Your code is your image, it shows your personality.
Keep In Mind
A simple list of things to keep in mind when creating a PR, some are strongly recommended, some are nice to have:
- Leave a brief description regarding PR content and functionality
- What is its content and how can it be seen or tested
- What is being accomplished by this merge
- Use images and/or videos to help understand its content
- How it looks on different resolutions
- What does it do
- For APIs a Swagger or Postman collection works just fine
- Rebase, squash and amends for PERSONAL git commit history. DO NOT override team history
- Only one feature/fix per PR. If the feature is big then it should be split into smaller features
- Do not include 500 files with +20k lines, don’t be that guy
- When giving a review keep in mind
- Be realistic. Do not ask for feature refactors if not needed
- Give constructive feedback, include links to documentation when suggesting design patterns
- General code details such as encapsulation, naming, architecture, performance
- Team code standards
- Keep branch updated with parent (dev, main)
- Use commit conventions
Continue reading