Opinionated Git

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.

For a more in-depth look at the difference between the two approaches please read merge vs. rebase by Edward Thomson.

Should I use submodules for dependencies

No, use a proper dependency management tool!

Also note that subtree and subrepo should be avoided.

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 use GIT, it is not an acronym!

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.

There is no such thing as hotfix branches. Especially when we are doing something urgent, we do not want to skip our pipeline and workflow. This is how production gets borked.

Do not make commits on master

When you are making a change to your code base, isolate your development on a separate branch. This allows for easier and safer experimentation.

It also allows you to easily switch context, should you feel the need to investigate different versions of your code, or the pressure to switch context because something is burning.

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: 1. git checkout feature/branchname 2. git rebase master 3. Test everything! 4. git checkout master 5. 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.

On Graphical Tools

I’ve often been a bit arrogant, and always have just said learn git in CLI, then you can cheat afterwards. I now feel very comfortable in the command line, but I think this is just me growing old and grumpy.

In most IDEs there are excellent Git integrations. You should learn and use these. If you have a day to day need for a separate Git client your workflow is overly complex. Simplify it.

The same goes for merge and diff tools. If you need external diff or merge tools, to me that is a workflow smell.

There is an excellent Git integration in for example VSCode.

That said I have worked together with people having great success with p4merge, meld merge and kdiff.

Most conventional editors can be configured as a diff or merge tool.