GIT: common mistakes

It’s important to know these common mistakes. It will save you a lot of time!

Commit vs stash

Git commits and stashes are snapshots. The big difference is that stashes do not appear in your GIT history, they are recorded in the stash list.

Unlike stashes, commits MUST appear in history, they are important changes you need to record, especially when working with your teammates.

Typical use is when you need to pull some changes from the remote branch because one of your teammates has pushed some commits you need to get. The problem is that you have made some modifications but not enough to add a new commit.

Losing that work is not an option but you do not want to commit unfinished work. Use git stash. It will save your work without recording it in the GIT history.

To recover your modifications after pulling your teammates' commits just run:

git stash pop


Branches and tags

What’s the difference?


In other words:

Usages and GIT spirit

Tags are often used to point to specific releases. It’s often used to deploy specific commits in production instead of just pulling master.

The idea is to use branches for unstable code and tags for stable versions/releases.

What is tracking in GIT?

3 Trees

GIT works with 3 trees:

You use the working tree when you code in your IDE, then you use git add to add your modifications in the index. After that you add a new commit to record your modifications. The HEAD will point to this commit.

git checkout

git checkout is like git clone but not really…

Updates files in the working tree to match the version in the index or the specified tree. If no paths are given, git checkout will also update HEAD to set the specified branch as the current branch. Source

What the hell ?!!!

This is your spaceship in the GIT universe, you will use it to switch between branches (update:_ **in the last version of GIT, there’s a new command GIT switch)**_.

Be careful though! Git checkout is not git pull, it does not grab the latest modifications. Please pull before.

The classic checkout error

A very common mistake that can have bad consequences. Always start any new branch from the main branch (master). Never start a new branch without checking that you have the latest version of the main branch on your local machine.

Otherwise, that’s the « best » way to introduce bad effects in the GIT history.

The safest method is:

git checkout master
git pull
git checkout -b my new branch

GIT interactive

The i option is very useful.

It will give you additional informations :

git add -i

It can be used to reorder and clean commits BEFORE git push :

git rebase -i

No more craps in the GIT history, you are now a ninja.

Be cautious with git clean

I don’t recommend using git clean in a production environment. It’s not safe and it might delete a lot of files, especially if your .gitignore file is not enough accurate.

However, if you want to run it, at least use the interactive option :

git clean -i

the –dry-run option is even better :

git clean --dry-run

Reset vs transparency

I prefer using git revert than reset. It’s safer, cleaner, and it’s great to learn from your mistakes.

A lot of beginners want to use reset to erase any track of their mistakes. It’s bad, GIT is not made to put the blame on people and if it’s used for that, your team is shitty and you should consider working elsewhere.

Reset and force push is a huge risk comparing to a simple revert.

Wrap up

GIT is a decentralized technology. 90% of the time, you will work locally.


I’ve discovered the following tricks the order day, try it:

sudo apt-get install lighttpd
cd mon-depot-git
git instaweb