Atelier animé par Alexandre Granier alias @zigarn dans le cadre du Capitole du Libre 2017 ayant eu lieu le weekend du 16/17 novmenbre 2017.

2h autour des merges

zigarn.com pour recuperer les slides.

première étape on clone l'espace de jeu

git clone https://bitbucket.org/zigarn/git-merge-workshop-workspace.git

git permet d'utiliser un outils externe pour gerer les conflits vi l'option mergetoo

on va utiliser kdiff3 3 pour base commune, evolution 1 et evolution 2

On rentre dans l'espace de travail et on lance le sript d'accueil

$ ./run.sh

pour faire un merge dans de bonne conditions, faire place net, pas de modif en cours

si des modifications sont en cours dans l'espace de travail, stash meme fichier non tracker ( –include-untracked) apres git stash pop pour les reappliquer localement

meme chose pour le rebase.

c'est quoi un merge? fusion entre 2 dossier. fusion du contenu d'une branche avec le contenu d'une autre branche. en plus git enregistre le point de fusion (notion d'historique).

graphe acyclique orienté (DAG) graphe represente la vue topologique la chronologie est indiquée par les indices

notion de parents(^) et d'ancetres(~)

lors du git clone on récupère tout mais les branches sont prefixées origin. Si on fait un checkout local avec une branche qui n'existe pas, on crée un branche locale si le nom de la branche existe sur origin, la reference locale pointe sur

git fetch: demande le delta d' evolution par rapport au remote

merge sans commit, pour lancer des test et verifier des choses

rembobiner sur la derniere action (dernier commit)

git reset --hard@{1}

merge signifie fusion, pour la plupart ddes gens il signifie conflit…

Attention: ne pas faire checkout origin/ techniquement on est sur le même commit mais sans branche (cas detached head) il faut créer une branche locale:

# revenir en arrière
$ git commit  -

pour revenir en arrière git checkout -

diff format unify (grâce au contexte 3 lignes dessus 3 lignes dessous.

permier a/runs.sh deuxieme b/run.sh

de la ligne 2 a 7

Dans le fichier, marquers de conflits

merge reconciliation de deux evolutions parrallele. l'ancetre commmuen est appelé BASE les branches paralleles sont appellées

OURS les notres (branche courante) premier parent
THEIRS les leurs branche a merge, deuxieme parent

Pour info connaître l’ancêtre commun, les evolutions faite de chaque coté

  git merge-base branch-C-1 origin/branch-C-2
 

lorsque conflit, on a acces aux differentes version

la version du fichier dans la base

git show :1:run.sh

la version sur ma branche 'OUR)

git show :2:run.sh

marqueur de conflit de type diff 3 permet de voir les delta entre la base, ours et theirs

En plein milieu d'un merge trop merdique,

git merge --abord

.gitignore fichiers a ignorer pour tout le mode .git/info/exclude pour son dépôt

en cas de mauvaise resolution sur un fichier du merge, on peut le redemander le merge juste

git checkout –merge fichier

• both le fichiers a ete modifie differement dans les deux branches
• * delete by them/us: le fichier a subit des modif mais supprimé par les autres
• both added: ajouter unfichier de meme nom des deux cotés mais avec des cotenues différents

pour un fichier binaire, via :1: :2: :3: on selectionne la version du binaire que l'on souhaite conserver. on met dans l'index et on commit.

Attentetion, c'est pas parcequ'un merge se passe bsans conflit qu'il n'y a pas de problème dans le code. Je peux modifier mon programme et appeler une methode dont la signature a evoluer dans un fichier differents dans la branche THEIRS par exemple. Le merge sera correct mais le code ne compilera plus.

Recommandations:

• merge –no-commit
• regarder le delta
• lancer la suite de tests

git cheat sheet décrit les commandes de facon interactive et reprensentes les différents espaces

• https://ndpsoftware.com/git-cheatsheet.html