Version Control (WIP)
Version Control (WIP)

General Guidelines

Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it’s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts.

You should only commit code when it’s completed. This doesn’t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature’s implementation into logical chunks and remember to commit early and often. But don’t commit just to have something in the repository before leaving the office at the end of the day. If you’re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git’s “Stash” feature instead.

Resist the temptation to commit something that you “think” is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing / sharing your code with others

Begin your message with a short summary of your changes (up to 50 characters as a guideline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions: What was the motivation for the change? How does it differ from the previous implementation? Use the imperative, present tense („change“, not „changed“ or „changes“) to be consistent with generated messages from commands like git merge.

Having your files backed up on a remote server is a nice side effect of having a version control system. But you should not use your VCS like it was a backup system. When doing version control, you should pay attention to committing semantically (see “related changes”) – you shouldn’t just cram in files.

Branching is one of Git’s most powerful features – and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, ideas…

Follow your teams agreed workflow and branching strategy

Reference:

https://www.git-tower.com/blog/version-control-best-practices/⁠

⁠

Code reviews

Code reviews play an important role in the development process helping to reduce bugs, ensuring standards and improving the overall health of the codebase. Please ensure that code you thoroughly review pull requests (PR) ensuring code quality and before approving. Do not rubber-stamp PR approvals for any reason.

Using welcoming and inclusive language

Being respectful of differing viewpoints and experiences

Gracefully accepting constructive criticism

Focusing on what is best for the team/org

Showing empathy towards other team members

Technical facts and data overrule opinions and personal preferences.

Reference the code style-guide whenever possible to help developers improve the quality of code in a PR

Leave comments that help a developer learn something new. Sharing knowledge is part of improving the code health of a system over time.

Guidelines Deep Dive

Add links to any additional information or guide lines you need

(TBD)

⁠

Code Examples

(N/A)

⁠

Foundations

If you need more infromation on the guidelines or you're not comfortable with subject matter, you can read browse the following resources:

⁠

How to Make Good Code Reviews Better⁠

⁠

Why code reviews matter (and actually save time!)⁠

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP