It’s important to know these common mistakes. It will save you a lot of time!
Permalink to heading Commit vs stash 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
Permalink to heading Branches and tags Branches and tags
What’s the difference?
Permalink to heading Distinguo Distinguo
- 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
Permalink to heading Usages and GIT spirit 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.
Permalink to heading What is tracking in GIT? 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.
Permalink to heading 3 Trees 3 Trees
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.
Permalink to heading git checkout 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
HEADto set the specified branch as the current branch.
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.
Permalink to heading The classic checkout error 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
Permalink to heading GIT interactive 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.
Permalink to heading Be cautious with git clean 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
Permalink to heading Reset vs transparency 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.
Permalink to heading Wrap up 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
Permalink to heading Useful links Useful links
I do my best to update all my contents, but keep it mind that "GIT: common mistakes" has been published many months ago.