Cela fait désormais quelques temps que nous utilisons git au travail. Pour être honnête, dans 95% du temps, nous arrivons tous à nous en sortir sans aller à la pêche au infos. Cependant, il arrive que parfois ce soit un peu laborieux. La démarche que j’ai adopté pour mieux appréhender l’outils fut d’acheter Pro git et de le lire. Sa lecture fut salvatrice à une époque ou DVCS était pour moi juste un acronyme sans beaucoup de signification…

Alors, après quelques petites galères rencontrées lors de l’utilisation de git, voici quelques petites astures trouvées au cours du temps lorsque quelqu’un criait dans l’Open Space

Mais ils sont passé où mes put**** de commits !!

Peut-être que ces quelques lignes permettront d’améliorer votre quotidien avec git !

Configurations globales

Bien sûr, quand on utilise git, il y a une chose à faire essentiel, c’est définir qui on est. Pour cela, voici les 2 commandes indispensables :

git config --global user.name "$PRENOM $NOM"
git config --global user.email "$MAIL_ADDRESS"

Si cela n’a pas été fait au préalable, vous allez alors partagé votre code de manière anonyme. Généralement, au sein d’une équipe, si tout le monde fait ça, garder un historique peut alors rapidement tourner au cauchemar !

Customiser le .bashrc / .profile

Vous aimez les lignes de commandes ? Cool, moi aussi :-) ! Et vous rêvez parfois d’avoir un PS1 clair. Voir de l’autocomplétion avec git ? Evidement que c’est totalement possible !! Voir même recommandé…

Tout d’abord, il faut commencer par télécharger 2 fichiers comme suit :

curl https://raw.githubusercontent.com/git/git/master/contrib/completion/git-prompt.sh -o ~/.git-prompt.sh
curl https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.sh

Et rajouter ceci dans le fichier .bashrc.

# Include git completion
. ~/.git-completion.sh
. ~/.git-prompt.sh

Pour le PS1, vous avez le choix de le surcharger à l’aide de la fonction __git_ps1 et vous aurez alors une intégration git parfaite. De mon côté, j’ai choisi de définir la variable d’environnement PROMPT_COMMAND comme suit :

## Colors
# Reset
_color_off='\[\033[m\]'       # Text Reset

# Regular Colors
_c_r_black='\[\033[30m\]'        # Black
_c_r_red='\[\033[31m\]'          # Red
_c_r_green='\[\033[32m\]'        # Green
_c_r_yellow='\[\033[33m\]'       # Yellow
_c_r_blue='\[\033[34m\]'         # Blue
_c_r_purple='\[\033[35m\]'       # Purple
_c_r_cyan='\[\033[36m\]'         # Cyan
_c_r_white='\[\033[37m\]'        # White

# Bold Colors
_c_b_black='\[\033[1;30m\]'        # Black
_c_b_red='\[\033[1;31m\]'          # Red
_c_b_green='\[\033[1;32m\]'        # Green
_c_b_yellow='\[\033[1;33m\]'       # Yellow
_c_b_blue='\[\033[1;34m\]'         # Blue
_c_b_purple='\[\033[1;35m\]'       # Purple
_c_b_cyan='\[\033[1;36m\]'         # Cyan
_c_b_white='\[\033[1;37m\]'        # White

# Exit status function
function __exitstatus {
	exstatus="$?"
	_prompt_start="[\T][${_c_r_red}\u${_color_off}@${_c_r_green}\h${_color_off}: ${_c_r_blue}\w${_color_off}"
	if [ "${exstatus}" -eq 0 ] ; then
		PS1="${_prompt_start}$(__git_ps1) ${_c_b_green}:)${_color_off} ] \$ "
	else
		PS1="${_prompt_start}$(__git_ps1) ${_c_b_red}:(${_color_off} ] \$ "
	fi
	#PS2="${BOLD}>${OFF} "
}
PROMPT_COMMAND=__exitstatus

Le principe de la variable d’environnement PROMPT_COMMAND est qu’elle soit executée comme une commande bash classique juste avant d’afficher le PS1. Si celle ci est définie, alors, la variable PS1 ne sera alors pas utilisée. Et en image, voici le résulat :

Pour les couleurs du bash, la page wiki de archlinux qui est très bien faite et pourra vous donner plein d’idée de couleur Color Bash Prompt !!

Sinon, vous pouvez aussi vous amusez à générer vous même votre PS1 grâce à un PS1 generator.

Le fichier .gitignore

Le fichier .gitignore n’est plus à présenter tellement sa renommé est désormais célèbre ! Chacun copie un peu son .gitignore de projets en projets afin qu’il soit un peu complet. Personnellement, voici le fichier .gitignore que j’utilise au sein de mes projets Java :

# Java
*.class
*.jar
*.war
*.ear
hs_err_pid*

# Maven
target/
pom.xml.tag
pom.xml.releaseBackup
pom.xml.versionsBackup
pom.xml.next
release.properties
dependency-reduced-pom.xml
buildNumber.properties

# Eclipse
.settings
.project
.classpath

# IntelliJ
.idea
*.iml

# Code quality plugins
.pmd
.checkstyle
.pmdruleset

Ce fichier est le fruit d’une concaténation de gitignore que vous pourrez trouvez sur ce repo Gitignore Github ainsi que de quelques erreurs de commits !!

Le fichier .gitattributes

Autant, nous connaissons bien le fichier .gitignore afin d’ignorer certains fichiers. Autant, le fichier .gitattributes est souvent (et à tort) bien méconnu.

Par exemple, si vous travaillez sous windows avec cygwin et que, avant chaque execution d’un .sh (parce que c’est quand même vachement plus classe qu’un .bat à écrire :-P), vous vous retrouvez sans arrêt à faire des dos2unix, et bien le fichier .gitattributes est fait pour vous !!

Mais ce n’est pas la seule fonctionnalité de ce petit fichier ! Vous pouvez identifier vos binaires et même dire explicitement à git comment les comparer.

*.sh        eol=lf
*.docx      binary
*.png       diff=exif

Lorsque vous utilisez un diff custom, il vous faudra alors rajouter la ligne suivante dans votre configuration :

git config diff.exif.textconv exiftool

Pour plus d’information, n’hésitez pas à consulter la documentation :

• man page - gitattributes
• Customizing Git - Git Attributes

Tiens, mon shell me dit qu’il est bien tard…

Alors, happy coding !