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 Separer 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