%Git flow %Malik Bougacha %10 Septembre 2015
Git sans workflow
\center \includegraphics[width=4cm]{img/git_crazy.png}
- Adapter git à l'usage. \pause
- Minimum de gestion de conflit dans la production. \pause
- Environnement suivant:
- Feature
- Dev
- Prod \pause
- Il devrait être possible d'appliquer un bug fix à la production et au développement.
- Il devrait être facile de sandboxer et de partager des essais. \pause
- Il devrait être facile de promouvoir du code d'un environnement à un autre. \pause
- Conflits gérés par le développeur et non pas par l'intégrateur. \pause
- Simplicité de patch pour la production et le développement.
Environnement --> Branche (set de code)
\pause
Branches:
\pause
- Feature
- Développement
- Release
- Production (master)
- Hotfix
Branche de feature:
- Nom de la feature.
- Branche à la durée de vie courte.
- Amélioration d'un composant.
- Basée sur la branche de développement.
- Mergée dans la branche de développement.
\pause
Emplacement des résolutions des conflits avec la branche de développement
- Branche d'intégration des features.
- Branche active à la durée de vie longue.
\center \includegraphics[width=3cm]{img/gitflow-feature.png}
- Branche de pré-production.
- Branche active à la durée de vie courte.
- Branche à la durée de vie longue (toujours sur la remote).
- Merge depuis la branche de développement.
- Tag de version.
\center \includegraphics[width=3cm]{img/gitflow-release.png}
-
Branche à la durée de vie courte.
-
Basée sur production.
-
Merge sur la branche de développement ainsi que sur celle de production (master).
\center \includegraphics[width=3cm]{img/gitflow-hotfix.png}
\center \includegraphics[width=4cm]{img/gitflow.png}
git checkout -b feature
git add new_file old_file anything.jpg
git diff --staged
git commit -m 'adding element for feature'
git checkout develop
git merge --no-ff feature
En cas d'absence de conflit, git fast-forward
- Perte de l'historique
- Absence du commit de merge explicite
\pause
Ajout du --no-ff
- Création automatique d'un commit de merge.
- Historique conservé
\center \includegraphics[width=7cm]{img/merge-no-ff.png}
Toujours runner git status
.
En cas de problème, git status
\pause
\center \includegraphics[width=7cm]{img/status_all_the_things.jpg}
git merge --abort # safe stop
git checkout feature_critical
git merge --no-ff develop
#RESOLUTION DE CONFLICT!
git checkout develop
. . .
git merge --no-ff critical_feature
\center \includegraphics[width=2cm]{img/push-n-pull-result.png}
git checkout develop
git pull --rebase
\pause
Conflits gérés en downstream dans les branches de feature.
\center \includegraphics[width=2cm]{img/push-n-pull-rebase-result.png}
Met les repos locaux en dessus des commits déjà présents dans la remote. Les références des commits locaux changeront. Historique linéaire.
- Change la base de la branche.
\pause
- Change le SHA des commits.
\pause
- Change les commits.
\center \includegraphics[width=5.5cm]{img/gitflow-rebase-feature.png}
traduction:
J'ignore ce qui se trouve actuellement de l'autre côté.
\pause
J'écrase les références existantes et les remplace par la mienne.
\center \includegraphics[width=7cm]{img/burn_remote.jpg}
\center \includegraphics[width=7cm]{img/git_absolute.png}
- Ne jamais utiliser push force.
\pause
En cas d'exception se référer à la ligne d'avant.
\pause
- N'utiliser le rebase que sur les branches locales
- Dans le doute, utiliser le
merge --no-ff
.
git checkout master
git merge --no-ff develop
git push origin master
\pause
Pas de conflit de merge Version simplifiée
git tag 0.1
git push --tags
- Alias au SHA, référence fixe du commit.
\pause
- Différent d'une branche.
Problème du workflow précèdent:
- Transparence.
- Peer review.
- Interface ruby on rail for git remote.
- Gestion des accès par repository.
- Merge dans la branche de développement des features sont publiques.
- Déploiement en production fait de la même manière.
- Review des demandes de merges.
- Est-ce que je comprend ce qui a été mergé ?
- Est-ce que le nom des méthodes est logique et compréhensible ?
- Nom des variables est correcte et compréhensible ?
- Une partie du code peut être mieux écrite ?
\pause
- Partage des responsabilités.
- Gestion des modifications des fichiers à travers la GUI.
- Création des branches
- Visualisation et édition de l'historique.
- Merge request.
- Un fork est simplement une autre remote.
- Public pour des contributions a l'open source ou publication.
- Tous les laboratoires de l'EPFL sont dessus. \pause
- Ce talk aussi !
- En allemand: https://github.com/esc/clt-2015-git-workflows (Utilisation des schémas git)
- Gitflow par commandes: https://github.com/nvie/gitflow.git
- Gerrit flow: http://docs.openstack.org/infra/manual/developers.html