Git Flows

<aside> 💡

Best practices must be enforced via Github Repo settings. If we want to see best practices, but best practices take more effort to do, then we will naturally succumb to not best practices. Computers are great because they’re programmable, so let’s program rules in place

</aside>

• No merge commits onto main
• No direct committing to main, even if you’re admin. If you need to POC, then your code should be buildable from a feature branch. If it’s an emergency, then let’s talk
• Only live code on main
  • Eg. if we’re going to base our code off another project, we shouldn’t just blindly fork and then build off from there. Rather, it should be:
    1. Create Empty Repo called new-feature
    2. Fork old repo to create fork-of-old
    3. Make changes to fork-of-old to what your new project needs
    4. Create PR from fork-of-old to new-feature. This way all code that hits main gets reviewed.
  • Having dead code is really hazardous because it creates a mental burden. If we need to draw inspiration from another project, then we should. But code should be kept clean for the purposes of each repo. This is why any unused methods should be deleted. Again, tooling helps, eg pylint’s unused argument checker: https://pylint.readthedocs.io/en/latest/user_guide/messages/warning/unused-argument.html.
• Resolve all PR comments before merging — issues slide through otherwise

Code Hygeine

• Linter
• formatter
• B/c when code is written a standard way, diffs become easier to read– it’s pure content instead of moving stuff around.