Should I rebase or merge?
A very common question is “Should I merge or should I rebase?”. Always do rebases. It makes your history look prettier.
Should I use submodules for dependencies?
No, use a proper dependency management tool!
Monorepo or many-repos
If you find yourself building specific tooling in order to accommodate a huge repository, you should split up your repository.
How do I spell Git?
Use Git for the tool, the community, the concept. use
git for the cli tool.
Never user GIT, it is not an acronym?
What is the recommended Git workflow
Do trunk based development - DORA says it is the best way to do. Integrate often. Only long-lived branches should be maintenance branches.
Proactively deprecate maintenance branches that are no longer needed.
Have shortlived feature branches - they should not live longer than a day.
Do not make commits on master
Isolate your changes to feature branches. Always assume you will be working on more than one thing at a time. Feature branches allows for easier switching of concepts
Only fast-forward merge the master branch
If you do not have any automate the correct workflow for getting changes to the master branch is:
git checkout feature/branchname
git rebase master
- Test everything!
git checkout master
git merge feature/branchname
Isolate your work, preserve your master branches.
Practice Continuous Integration
Automate your quality criteria. Protect your master branch as that perfect truth it is.
On commit messages
Commit messages are important, and there are some many great examples of bad commit messsages.
A commit message should concisely describe what is the consequence of applying a commit.
In real life you will also be using a task management system, a commit should be done in context of a task, and such the task should be referenced from the commit.
Take advantage of the fact that you have both a subject and a body to elaborate on your commit message. Put task references in the body.
I expect you to make small commits, so I don’t want to see a novel in the commit message. It is probably better suited either in a changelog, the documentation or inline in the code.
Read How to Write a Git Commit message by Chris Beams.