nutools/doc/pdev.md

86 lines
4.3 KiB
Markdown
Raw Normal View History

# pdev
~~~
pdev: basculer sur une branche de développement
USAGE
pdev [FEATURE [SOURCE]]
pdev -m|-l|-d [FEATURE]
- Vérifier l'existence de la branche develop. La créer si nécessaire en la
basant sur [origin/]master.
- Vérifier s'il n'y a pas de modifications locales. Sinon, proposer de faire un
commit ou un stash.
- Si FEATURE est spécifié, et si on n'est pas déjà sur cette branche, basculer
vers cette nouvelle branche. S'il s'agit d'une nouvelle branche, la baser sur
la branche SOURCE, qui vaut par défaut develop
- Si FEATURE n'est pas spécifié, basculer sur develop s'il s'agit de la seule
solution, sinon afficher un menu pour choisir la branche de destination.
OPTIONS
-C, --projdir PROJDIR
Spécifier le répertoire de base du projet qui est dans git. Par défaut,
on travaille dans le répertoire courant et on laisse git trouver le
répertoire de base du projet. Avec cette option, le répertoire courant
est modifié avant de lancer les commandes git.
-O, --origin ORIGIN
Spécifier le nom de l'origine. Par défaut, utiliser 'origin'
-o, --offline
En cas de création d'une branche, ne pas pousser vers l'origine; ne pas
tenter le cas échéant de traquer la branche dans l'origine; ne pas
supprimer une branche dans l'origine. Cette option est automatiquement
activée si la variable UTOOLS_VCS_OFFLINE est définie.
--online
Annuler l'effet de la variable UTOOLS_VCS_OFFLINE: forcer le mode online
--sync
Faire un certain nombre d'opération pour 'corriger' le dépôt local: pour
chacune des branches distantes, vérifier qu'il existe une branche locale
qui la traque, et pour chaque feature branche locale, vérifier qu'il
existe une branche distante associée. Cette option nécessite --online
-s, --squash COMMIT_MSG
Si la branche actuelle est une feature branch, la merger comme un seul
commit avec le message COMMIT_MSG dans develop puis la supprimer. Puis
basculer sur la branche develop.
Cette option ne devrait pas être utilisée avec -k, puisque bien que les
modifications soient mergées, la branche elle-même n'est pas considérée
comme mergée. Les résultats sont donc indéfinis si la branche est mergée
à plusieurs reprises.
-b, --rebase
Si la branche actuelle est une feature branch, lancer 'git rebase -i'
sur la feature branch. Cela permet de réordonner les commits pour
nettoyer l'historique avant de fusionner la branche avec -m
Cette option devrait le cas échéant être utilisée immédiatement avant -m
ou alors il faut forcer le push et communiquer avec l'équipe sur le fait
que la branche de feature a été rebasée.
-m, --merge
Si la branche actuelle est une feature branch, la merger dans develop
puis la supprimer. Puis basculer sur la branche develop.
--merge-log
Ajouter un résumé des modifications sur la feature branch en ajoutant le
log en une ligne de chaque commit dans le message du merge. Cette option
n'est en principe pas nécessaire puisque 'prel -um' intègre la liste des
commits dans CHANGES.txt
-k, --keep
Avec l'option -m, ne pas supprimer une feature branch après l'avoir
fusionnée dans develop. Cela permet d'intégrer les modifications petit à
petit.
--delete
Supprimer une feature branch, à condition qu'elle aie déjà été
entièrement fusionnée dans la branch develop
--force-delete
Supprimer une feature branch, même si elle n'a pas encore été fusionnée
dans la branche develop
-l, --log
-d, --diff
Afficher les modifications entre deux branches. L'option --log affiche
les modifications dans l'ordre alors que --diff affiche les différences
sous forme de diff. Les deux options peuvent être combinées et ont
l'effet de 'git log -p'
La branche comparée, s'il elle n'est pas spécifiée, est par défaut la
branche courante. S'il s'agit d'une feature branch, elle est comparée à
develop. S'il s'agit de la branche develop, elle est comparée à master.
~~~
-*- coding: utf-8 mode: markdown -*- vim:sw=4:sts=4:et:ai:si:sta:fenc=utf-8:noeol:binary