This is a quick Subversion (SVN) guide for Git users. This article helps you to get started with SVN right away, the Git way.

I originally wrote this article for Codementor in October 2014. It should have something for everyone, from fairly new git users to…

Who is not tired of committing a "Remove pdb" or a "Fix a typo" few minutes or hours after committing a clean feature ? A few time ago, I discovered two useful options in GIT that work together : git commit --fixup and git rebase --autosquash. With these, you can easily merge little fixes with the original feature and keep your branch clean.

Wer ein Programmierprojekt angeht, wird früher oder später auch auf Git treffen. Wir haben dir eine einfache Übersicht über alle wichtigen Befehle zusammengestellt. Damit gelingt dein Einstieg garantiert.

Magit User Manual: Top

Blog of Jonas Bernoulli

Charl Botha has a useful video on rewriting Git history with Magit. Botha gives three examples:

1. Changing the commit message on any old commit
2. Squashing two or more commits into one
3. Splitting a commit into two or more separate commits

One of the most important (and confusing) git features in my new job was rebasing. Looking back now, the worst part was not finding a clear beginner's guide. So for the past me, and any future devs like the past me, this intro is for you!

Git rebase is one of those commands that you may have heard of as a substitute for merge. Truth is, it’s more than that — rebase is a completely different set of tools that intersect with the…

Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can't search for how to get yourself out of a mess, unless you already know the name of the thing you need to know about in order to fix your problem.

So here are some bad situations I've gotten myself into, and how I eventually got myself out of them in plain english*.

A guide for programmers using git) about what to do when things go wrong.

This is why writing down notes on everything I read is an important habit I've sadly let falter. My own preference is a Github repo full of markdown files with notes on books, blog posts, and whatever else I want to save for later. Important syntax rules, term definitions, personal tricks or ideas, quotes or summaries - I write down anything I find inspiring or useful from the texts

Git is made for, and encourages, non-linear history. If that puts you off you might be better off using a simpler VCS that only supports linear history.

I think you should keep your history true. Get comfortable with tools to analyse it, and don’t fall for the temptation to rewrite it. The rewards for rewriting are minimal, but the risks are great. You’ll thank me the next time you are bisecting through your history to track down a sneaky bug.

Frequently used commands