I see a lot of complaints about git submodules, people suggesting alternatives, complaints about merging or other bits and pieces.

Git submodules have their place. Yes they are not ideal for all situations but they are ideal for the typical use case I’m about to outline.

Example use case

In my work I have a master project which contains multiple submodules. Each submodule is also cloned into a separate development repository sitting near by. I use the master repository to synchronise pushes to the deployment server (in this case an isolated computer sitting on a mountain in Chile!)

So git rebase is a powerful tool, able to change history itself. With this power however requires great care to avoid needing to git push --force.

Git rebase comes with very user friendly ways to cancel out of a rebase if something goes wrong or if you become confused:

git rebase --abort

This returns your working tree back to the state before the rebase was started.

One thing that has always made me nervous when using rebase was when I rebased and a conflict occured, so I only kept changes from the HEAD commit which caused the following message:

Git quick is a simple shell command I’ve written for quicker one line messages. It allows committing like

g q A simple commit message

Note the lack of quotes. Some things I’ve used to make it quicker:

• alias git to g in my zshrc
• alias q to quick in my gitconfig file
• put the git-quick script into my path somewhere

The script

The script really can’t be much simpler:

Today I found out that .gitignore files can be nested.

For example the directory tree

a
a/b
.gitignore
a/b/.gitignore

can have files in b ignored by a/b/.gitignore.

This helps split the responsibility of ignoring files by topic and really helps organisation!