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 commit.

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.

DO's

  • 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.

DONT's

  • 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".

Addendum

git help

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

[user]
    name = Thomas Lionel SMETS
    email = Thomas.Smets@a3-system.eu
    password = "<HIDDEN>"


[alias]
  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


[core]
    excludesFile=~/.gitconfig-ignore

[pull]
    rebase = true

.gitconfig-ignore

*~
**/*.*.bak
**/*.*.BAK
**/logs 
*.pdf