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?
- a branch can be modified
- a tag is a milestone, it’s not supposed to change over time
In other words:
- with branches, you have several versions of the same code
- with tags, you have 1 and only 1 version of the code at a specific time
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?
- untracked files are files that won’t be taken into account for the next commit
- remote-tracking-branch is a local copy of the remote branch. You need to run **git fetch **to update that local cache.
GIT works with 3 trees:
- working tree (~workspace)
- the index
- the HEAD
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 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
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.
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