Skip to content
gmaillet edited this page Nov 25, 2016 · 9 revisions

Quelques bonnes pratiques

https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/ http://rogerdudler.github.io/git-guide/index.fr.html

Modification du code

Pour chaque modification, même une toute petite, il faut faire une branche. https://docs.gitlab.com/ee/workflow/workflow.html Quand on a bien crée la branche "my_feature", fait des modifications du code, commit, push ; alors on peut faire la "Merge Request" sur le gitlab http://gitlab.forge-idi.ign.fr/socle/sd-socle/merge_requests avec le bouton "New Merge Request" et en selectionnant notre branche en tant que branche source, et la branche "dev" en target.

La revue de code

Ce document explique l'intérêt et l'importance de la revue de code. https://yalantis.com/blog/code-review-via-gitlab-merge-requests-code-review-must/ Quand le commit n'est pas accepté il faut re faire son commit Voici un exemple de notre première revue de code !1 Séparer un commit en plusieurs commit La commande Rebase permet de placer la branche sur laquelle on se trouve après les dernières modifications de la branch master. Le -i fait que c'est interactif.

git rebase -i origin/master

ça ouvre un VI, on va mettre "e" (pour edit) au lieu de "pick". Pour quitter et sauvegarder dans VI :wq Pour annuler le dernier commit

git reset HEAD

Pour ajouter les modification à commit ( stage ) ; de façon interactive

git add -p

Pour mettre de côté (sur la pile de stash) les modification qu'on ne va pas commit ; mais garder l'idex (les modification à commit)

git stash --keep-index

Premier commit

git commit

Pour récupérer les modifications de la pile de stash

git stash pop

Second commit

git commit

Pour pousser les nouvelles modification

git push -f origin ma_branche

Clone this wiki locally