Archives par mot-clé : Git

Logo Git

Tips to dig into git log

Publié dans Développement | Laisser un commentaire
08 Déc 2023

I am a regular user of git dag <sourcefilepath> to check all commits applying on a single source file. You can also do it with gitk <sourcefile> but I always find git dag more convenient.

git dag interface

Recently, I had to check the changes made on a specific line of a source file. I started digging into 7 years of commits… and obviously it was time to search for a better option 🙂

Fortunately, git log is really powerful.

First you can list commits with an impact on a specific function using the -L option. The diff are display immediately which is pretty handy. For example: git log -L:sendTcpRequest:src/evcc/Evcc.cpp. The -L option be used for numerous other stuff, please check git log --help.

This was still listing dozen of diff. The -G option allows to directly search on all the diffs and list related commit. For example git log -G "flush" Evcc.cpp was listing me 3 commits with a diff containing the word « flush ».

The Rules of Life

Règle #2 – Changelogs & Release notes

Publié dans Développement | Laisser un commentaire
02 Juil 2019

Une bonne pratique de taille pour fiabiliser le développement logiciel, c’est de toujours garder une liste « humaine » des changements apparus de versions en versions.

On peut noter 3 degrés d’historique :

  • Git history : pour le développeur
    • git log, gitk
    • Moi je me suis créé un alias Git pour afficher joliment les derniers commits dans ma ligne de commande: git lasts
      • Ajouter l’alias suivant dans le fichier ~/.gitconfig: lasts = log -35 --pretty=tformat:"%C(red)%h%x20%C(magenta)%ad%C(auto)%d%x20%C(green)%s%C(white)%x20-%x20%an%C(auto)" --date=short --abbrev-commit --graph --decorate
  • Changelogs : pour l’utilisateur averti, pour le validateur
  • Release notes : pour le client, pour le « non technique »
    • Format à définir avec les personnes concernées
    • Focus sur les fonctionnalités et les changements visibles

Logo Git

Configuration de Git

Publié dans Geekeries | Laisser un commentaire
22 Avr 2014

Configurer Git (un gestionnaire de version décentralisé qui change la vie), est particulièrement utile et pas si compliqué. Il suffit de modifier un fichier de configuration.
La configuration globale s’appliquant à tous les repository Git se trouve dans le fichier .gitconfig se trouvant dans votre dossier utilisateur (i.e. ~/.gitconfig). Celle-ci peut-être surchargée par une configuration spécifique à chaque repository, via le fichier .git/config de chaque repository.

Voici typiquement à quoi ressemble mon fichier de configuration globale :

[user]
	name = Fylhan
	email = bnmaster@ahahah.fr
[color]
	ui = always
	branch = always
	diff = always
	interactive = always
	status = always
[push]
	default = simple
[alias]
	co = checkout
	br = branch
	st = status
	ci = commit -a -m
	last = log -1 HEAD
	lasts = log -35 --pretty=tformat:"%C(red)%h%x20%C(magenta)%ad%C(auto)%d%x20%C(green)%s%C(white)%x20-%x20%an%C(auto)" --date=short --abbrev-commit --graph --decorate
	lastpull = !git lasts HEAD --stat --no-merges
	showtag = !sh -c 'git rev-parse $1 | xargs git cat-file -p' -
	unstage = reset HEAD --
	undo = git reset --soft HEAD^

Continuer la lecture →

Cygwin, SSH Agent et un peu de Git

Publié dans Geekeries | Laisser un commentaire
05 Avr 2013

Cet article est une traduction (assez libre et agrémentée) de SSH Agent on Cygwin via kill the radio. Une autre resource pas mal sur le même sujet est disponible sur : Problem with ssh-add / ssh-agent under cygwin.

Il existe sûrement des dizaines de tutoriels sur l’art et la manière de démarrer un SSH Agent sur Cygwin, mais voilà qui peut toujours service !
Si jamais l’erreur suivante apparaît lorsque vous utiliser la commande ssh-add :

Could not open a connection to your authentication agent.

Cela signifie que vous n’avez pas de gestionnaire de clés SSH de démarré. Visiblement, il ne sert à rien de lancer le Pageant de Putty, il va donc falloir gérer tout ça directement dans Cygwin.
Continuer la lecture →

Logo Git

Ignorer des fichiers dans Git

Publié dans Geekeries | Un commentaire
04 Mai 2012

Dans le gestionnaire de version Git, la liste des fichiers à ignorer, c’est-à-dire à ne pas envoyer/récupérer sur/d’un repository Git est à mettre dans un fichier appelé .gitignore.

# Les ligne commençant par '#' sont des commentaires.
# Ignorer tous les fichiers nommés foo.txt
foo.txt
# Ignorer tous les fichiers html
*.html
# à l'exception de foo.html
!foo.html
# Ignorer les objets et les archives
*.[oa]

Et cela fonctionne pas héritage de dossier ! Donc, si on prend pour example la structure de dossier suivante :

.
dossierUn
  dossierA
dossierDeux

Un fichier .gitignore à la racine s’appliquera à tous les fichiers et dossiers sous-jacents (ici : « dossierUn », « dossierDeux » et « dossierA »).
Et il est possible de redéfinir des règles pour un dossier spécifique en rajoutant un fichier .gitignore, par exemple dans le dossier « dossierUn ». Ces modifications s’appliqueront alors à tous les fichiers et dossiers du dossier « dossier1 » (ici : « dossierA »). On peut alors ajouter des règles (ex : « *.php »), ou en surdéfinir certaines (ex : « !*.html » pour ne plus ignorer les fichiers HTML dans ce dossier).

Quelques ressources

Logo Git

Faire comme « SVN revert » mais avec Git

Publié dans Geekeries | Laisser un commentaire
29 Nov 2011

Scénario habituel nécessitant l’utilisation d’un svn revert : vous avez modifié un fichier (géré par SVN) sans le vouloir (ou vous avez changé d’avis !) et vous voulez retourner à la version actuellement géré par SVN. Un appel svn revert <nom du fichier> écrasera ce fichier avec la dernière version commitée sur SVN.
On peut faire la même chose avec le gestionnaire de version Git, sauf que cette fois-ci la commande à utiliser est git revert HEAD~<nombre de commit à effacer>, sans oublier de faire un push par la suite. Sam & Max explique ceci très bien dans un billet git revert pour annuler proprement le dernier commit.

Auparavant, j’utilisais git reset --hard <nom du fichier> ! Ou sur Eclipse avec le plugin EGit : clic droit > team > Reset et sélectionner l’option « hard ». C’est un petit peu différent vu que cette fois-ci on revient à la version d’une autre branche (par exemple : la branche sur le répertoire « origin ») alors qu’avec « revert », on reste en local. Mais avec « reset », il est possible de ne toucher qu’un seul fichier !

En fait, il est possible d’aller un peu plus sur ce sujet avec Git, mais un article l’explique déjà très sur Git Community Book : Undoing in Git – Reset, Checkout and Revert.

Logo Git

Lier une branche Git locale à la branche remote correspondante

Publié dans Geekeries | Un commentaire
09 Nov 2011

Quel est le problème ?

Imaginez que vous avez créé une branche sur votre reposiroty Git nommée « MaBrancheAMoi ». Et que lorsque vous désirez faire un « pull », Git vous renvoit le message d’erreur suivant :

You asked me to pull without telling me which branch you
want to merge with, and ‘branch.MaBrancheAMoi.merge’ in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. ‘git pull ‘).

Ce qui le plugin EGit d’Eclipse nous traduit généralement par le message d’erreur suivant :

no values for key « branch.MaBrancheAMoi.merge » found in configuration

Cela est dû au fait que vous avez une branche locale, mais Git ne peut pas savoir avec quelle branche en ligne (remote) la lier.

Continuer la lecture →