101 of Git Commands
Across the projects & users, we recommand to use a similar
.gitconfig file should be used
For ease of use a unique
.gitconfig file should be used.
Also the file types that are forbidden to be checked into the Git repository should be defined for every body. It is not considered as a good practice to commit binary files in the Git ... but sometimes teams do.
The fact that the file with the alias is common/shared across the team(s) allows to exchange best practice & common behavior. It is however not mandatory, just an advice.
Identifying changed files
git ps or
git -p status will provide the list of files that have been modified. The
-p stands for paginated. Pagination help to realise there are too many files modified.
What has changed in a file ?
The following command will show what has changed in the file since the last
checkout (or since the last
git add for that file).
git diff <file_name>
There is also the possibility to show the difference side-by-side. See the interesting post.
Once you have added all the files that you have modified for one change request, you should commit those.
Adding files to the next commit
The following will add all the translations for my project
git add ./locale/*/LC_MESSAGES/django.po
Avoid adding all the files at once with a command like :
git add .
It work beautifully until you push too many files at once and end up with binary or you password file in you repository.
Attention : Once you add a file, you only add the modifications of the files in the scope for the next
Committing the modifications
The command is really simple and straight forward :
git commit -m _<my usefull message>_
It is really crucial to put a meaningful message as it is what the users will have to quickly identify the commit that is of interested to them.
- Ensure that before each commit the code compiles, unit tests do not return more failures. Anybody choosing your commit (cherry picking) should have a great likelihood to have running code.
- You should create commit right the just size. Some made micro commits and tend to forget testing them before committing. Some tend to create massive commits that include 200 modifications.
- Describe how it was done. A message like : "Change line 3 of the styles.css" is completely useless. Instead the message should have been : "Fix ticket RSQ-5897 : now the right green is used in the background of templates".
The typical command is
git help <specific_command>.
git help diff
Beware that the help is sometimes very long. Worst, the interesting command are not always in the beginning.
Sample .gitconfig file
name = Thomas Lionel SMETS
email = Thomas.Smets@a3-system.eu
password = "<HIDDEN>"
co = checkout
br = branch -a
lg1 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(black)%s%C(reset) %C(dim blue)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all
lg2 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(black)%s%C(reset) %C(dim blue)- %an%C(reset)' --all
logs = log --oneline --pretty=format:"%h%x09%an%x09%ad%x09%s"
lg = !"git lg1"
ps = -p status
last = cat-file commit HEAD
st = status
ci = commit
pll = pull -v
ftch = fetch -v
rebase = true