Git best practices

This guide is an attempt to produce some best practices for git so we can maintain a consitstenct readable repository history while making code reviews easier

commits should be small and focused

Commits should be small and should be focused on doing one thing or area at a time where possible this is to make both the history more readable and code reviews easier aswell as being easiery to identify where defects have been introduced and apply reverts simpler.

Do not commit compile errors and broken code try to keep it a semi runable state

Write meaningful commit messages

Commit messages form a crucial part of the history of a feature and how it was developed, meaningful commit messages make scanning a features history easier and code reviews become much more simpler

Follow semantic commit messages where possible this also helps enforce focused commit messages.

Also include the issue number in the commit message where possible. This makes tracking down commits related to features long after they have been originally developed and backporting specific features becomes much easier rather than an exercise in copy paste.

feat: add hat wobble

^--^ ^------------^
| |
| +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

https://seesparkbox.com/foundry/semantic_commit_messages

commit early and often

Commiting early and often helps keep track of your work progress and stops you from losing work due to crashes or accidental deletions, while also allowing you to go back if something didn’t work out. it also helps ensure focused commit

Work on local feature branches updating from master often

all new features and work should be started as local feature branches on your local machine you should aim to update your work in progress feature branch from master often via rebase to avoid merge markers and a continuous linear change history

Enable all the git_hooks if available

git hooks are there to stop silly mistakes being committed as part of your code and to stop you from distributing the silly mistakes to everyone else. If they are available for the project you are working on, use them

  • Do not use git rebase on master or develop branch only on branch you alone are working on
  • consider pushed code shared with others final
  • Don’t commit personal configuration files these should remain on your machine or be added to the gitignore
  • Run tests before you push