Coding style isn't important for a project that's purely for learning, but we might actually be using the result. Thus here are a few suggested guidelines; they are currently simply Christian's, if you don't agree with them, say so. These aren't meant to enable policing activity, but are thought of as good practices that make the result easier to read and work with.
keep line length below about 72 columns; this isn't just an archaic leftover from small monitors, but because it allows for multiple windows to be viewed side by side, and because it's easier to read text with shorter lines. If your indentation grows that deep, it's time to break up the current function anyway.
In commit messages, follow the Git convention of using the first line as a 'subject', then an empty line and then detailed text if necessary. Wrap lines (on about column 72; use your editor's line rewrapping feature). Write about what the patch does, not what you did (i.e. "add foo function" and not "added foo function"), this makes more sense when viewing the commits as change sets (e.g. as patches on a mailing list). Don't end the subject line with a ".", just like with subjects of emails. Christian usually starts them in lowercase, too, as he thinks that these are like items in a list, although that may not be universally liked.
Git history should not be modified once it's public, but it's rather normal to clean it up beforehand. This allows you, while experimenting with coding approaches, to commit often without thinking, and then still create clean patches once you know how to get to the result. Clean patches are good because they make working with history nice (understanding code by examining its history, git cherry-pick, git bisect). Christian is using his own cj-git-patchtool for the purpose, there are more well-known alternatives, often git rebase -i or git merge --squash are fine solutions, too.