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.

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!