Sommaire
Configuration Git
Configuration obligatoire du ~/.gitconfig :
[user]
name = Prénom Nom
email = prenom.nom@pasteur.fr
[branch]
autosetuprebase = alwaysAlias utiles :
[alias]
co = checkout
st = status
ci = commit
br = branch
ds = diff --staged
unstage = reset HEAD --
amend = commit --amend --no-edit
lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=iso --branches --tags --remotesWorkflow Git
Le workflow se base sur Git Flow dans les grandes lignes. La branche develop contient les développements de la prochaine version, et master représente la version déployée sur le server Shinypro.
Développement d'une nouvelle feature :
A faire sur develop !
$ git checkout develop
$ git checkout -b feature/ma-nouvelle-feature
... réaliser les développements
$ git commit -a
$ git push -u origin feature/ma-nouvelle-featureCréer la Merge Request (banche feature/ma-nouvelle-feature -> develop dans GitLab. Référencer l'issue concernée dans le message de merge (en écrivant issue #num-de-l'issue)
Correction de bug lié à une issue :
A faire sur develop !
$ git checkout develop
$ git checkout -b bugfix/mon-bugfix
... réaliser les développements
$ git commit -a
$ git push -u origin bugfix/mon-bugfix Créer la Merge Request (banche bugfix/mon-bugfix -> develop dans GitLab. Référencer l'issue concernée dans le message de merge (en écrivant issue #num-de-l'issue)
Hotfix :
Utilisé pour corriger rapidemment uetne erreur directement sur master, sans passer par develop.
$ git checkout master
$ git checkout -b hotfix/mon-hotfix
... réaliser les développements
$ git commit -a
$ git push -u origin hotfix/mon-hotfixCréer la Merge Request associée dans GitLab. Une fois la branche mergée dans master il est possible de cherry-pick les commits sur develop par exemple :
$ git checkout develop
$ git cherry-pick identifiantducommit1
$ git cherry-pick identifiantducommit2
$ git pushMAJ de master sur une nouvelle version (à déployer sur le server) :
Commencer par créer un tag sur develop lorsqu'une version satisfaisante pourrait être déployée
$ git checkout develop # (1)
$ git merge master # pour être sûrs que develop dispose de tous les commits de master (2)
# doit renvoyer "already up to date". Sinon, un commit de merge sera ajouté, avec de potentiels conflits.
$ git tag # pour voir les tags existants
$ git tag -a vx.x -m "stuart version x.x"
$ git push origin develop --tags # (3)Une fois que le déploiement est validé, on met à jour master sur le tag créé
$ git checkout master # on retourne sur master
$ git merge --ff-only vx.x # on remonte master au niveau du tag en fast-forward (4)
$ git push origin develop master --tags(1)
master o o develop
| |
o o
\ /
o
|
(2)
o develop
/ |
/ |
master o o
| |
o o
\ /
o
|
(3)
o develop
|
o vx.x
|
o
/ |
/ |
master o o
| |
o o
\ /
o
|
(4)
o develop
|
master o vx.x
|
o
/ |
/ |
o o
| |
o o
\ /
o
|NB : les tests doivent être faits après l'étape (2), une fois que develop dispose de tous les commits de master.
Si une branche de hotfix doit être créée à partir de master créer la branche de hotfix à partir de ce point.
Impotant :
- Toujours vérifier l'état di repository local avec
git lgavant de les push sur le dépot distant. - Une fois une Merge Request est mergée sur gitlab, vérifier le graph en ligne avant de pull les mises à jour en local : en cas d'erreur de merge, on peut forcer un pushde la version local sur le repository distant pour "annuler" le merger (en cas d'erreur dans le choix des branches par ex)