7. Git best practices

While no productivity system is perfect, especially in team efforts, there are several best practices that can facilitate fast code deployment. After reading other people's systems and beta-testing each one, I am now offering my own set of best practices that I hope will help you with your future software development and collaborations.

1. Create branches that are specific to a particular problem

The default branch you start off with when initially tracking your folder using Git is master. It is common to reserve the master branch for the finished software product while developing code on other branches. Each branch can be made for a specific task, however I do recommend 5 branches to make every time you start a repo: a) A username branch (ie scampit for yours truly) * I typically start working with the code in this branch, and then create new branches if the task I'm working on needs significant development time. b) A feature branch (ie make_website_sliderbar) c) An issue branch (ie fix_X_bug) d) A dev branch for pre-production e) A version branch for specific version your code may exist in.

2. Commit and push your changes often

I have found that making commits after finishing even the smallest tasks and pushing those changes in a pre-production branch helps a) keeping track of what you're working on, especially if you look at your commit history, and b) saves A LOT of time if you f****d up.

3. Write great commit messages

Excellent commit messages can save a ton of time and can help other team members follow your work seamlessly. My suggestions for writing commits: a) For short (and simple) commits, it is only acceptable to use git commit -m "message" if you can write a summary of your changes in less than 7-10 words. Otherwise, write a full commit message using git commit. b) Keep your subject line less than 7-10 words summarizing what your changes are. If you can't do that, you need to commit more. c) Separate the subject line from the body with a new line. d) In the body of the commit message, explain what you have done and why you have implemented a change in the code.

4. Enforce code reviews, especially before pushing to the master branch

In projects with collaborators, I always set branch rules to enforce a code review in a Pull Request before merging changes to master. This is because I want the best code to go to production, and having multiple sets of eyes to review the code and offer suggestions is invaluable in catching your mistakes. Also, I found that it is a good learning experience for more novice coders to look at code, and critically evaluate it from a reviewer's standpoint. If it's possible, I'd suggest having someone review your work at the end of every workday, and reviewing other people's code frequently, even if it's not ready for production.