Bonjour,
Nous nous mettons à GIT (avec GitLab 6.5.1) au taff pour versionner nos environnements Puppet.
Nous avons un projet Dev, un projet PPRod et un projet Prod.
Nous travaillons sur le projet Dev/master; lorsque nous sommes content, un merge request est créé vers le projet de PProd/master.
- Nous travaillons sur le projet Dev/master, et commitons
- Nous créons un merge request de Dev/master => PProd/master
- Nous travaillons de nouveau sur le projet Dev/master et commitons.
Le commit réalisé en "3" n'est pas listé dans le merge request "2", cependant lorsque nous acceptons le merge request, il est mergé (sans pour autant être listé dans le merge accepté, mais nous le voyons dans la liste des commits du projet)
D'où mes questions :
Est-ce normal?
Un merge request est-il un lot de commit à un instant T (et mon fonctionnement est anormal) ?
Un merge request est-il attaché à une branche d'un projet (et donc à toutes ses modifications dans le temps, tant qu'il n'est pas accepté) ?
Merci
# Principe de la pull request
Posté par lay . Évalué à 2. Dernière modification le 13 février 2014 à 13:50.
Le concept de pull request n'est pas une fonctionnalité directement incluse dans git, c'est un concept créé par les outils de collaborations à un niveau supérieur qui a pour but de faciliter les merges de branches en les enrobant avec de la revue de code, refus/acceptation, etc.
Donc oui, un pull request à pour finalité un merge d'une branche dans une autre, et comme c'est un merge normal, tout les commits de la première sont mergés dans la seconde.
Certainement que l'outil que vous utilisez liste les commits au moment de la création de la pull request, puis merge simplement la branche même si elle contient des commits en plus.
Il faut revoir vôtre workflow, ne pas merger master directement, mais avant de faire une pull request, vous créer une nouvelle branche à partir de master ayant un nom en correspondance avec la modification et c'est celle ci qui doit être mergée dans pprod. Ainsi vous pouvez continuer a commit dans master sans aucun impact.
Une fois mergée, vous pouvez supprimer cette branche temporaire directement après le merge.
[^] # Re: Principe de la pull request
Posté par GaMa (site web personnel) . Évalué à 2.
J'ai jamais utilisé gitlab, mais ça me surprend qu'il fasse des pull request basé sur la branche seulement.
Pour moi un pull request doit être basé sur les commits (ou des tags).
Le workflow que tu (M.Poil) décris est relativement classique et un simple pull request basé sur le commit résout le problème (c'est ce qui se passe sur le kernel avec les pull request par mail).
Tu devrais voir avec les support autour de gitlab pour voir comment faire (et tu peux aussi revenir donner la solution en commentaire quand tu l'auras trouvée :) )
Matthieu Gautier|irc:starmad
[^] # Re: Principe de la pull request
Posté par lay . Évalué à 1. Dernière modification le 13 février 2014 à 14:29.
Tu as certainement raison de dire qu'une pull request doit être basée sur un commit pour cet usage, pour moi c'est plus plus propre et git l'intègre: git merge commit-id.
Mais cela dépend surtout de l'outil utilisé, ici au taff le logiciel de gestion de repos (Stash) n'offre pas cette possibilité et force l'utilisation de branches à tout les coups.
Je connais pas gitlab non plus mais si il n'offre pas non plus cette possibilité je serrais curieux de savoir pourquoi ces logiciels brident cet usage.
[^] # Re: Principe de la pull request
Posté par NeoX . Évalué à 3.
changer la branche pour n'y integrer que les versions "stables"
tu as alors une branche dev, une branche stable.
dans la branche stable tu envoies les correctifs validés
ensuite la prod prend toujours la branche stable.
[^] # Re: Principe de la pull request
Posté par Nerdiland de Fesseps . Évalué à 1.
Pour info sur Github (qui est une inspiration pour GitLab), il est possible de faire les deux types de pull requests, par rapport à une branche ou par rapport à un commit particulier ou un tag. Selon le workflow les 2 approches peuvent être valides.
Sur GitLab il semble qu'ils utilisent au moins l'approche par rapport à une branche. Tu as peut-être le bug décrit ici, si ta version de GitLab date une peu: https://github.com/gitlabhq/gitlabhq/issues/5054 . Comme ta request vient d'un autre repo, la liste de commits n'est pas correctement mise à jour.
[^] # Re: Principe de la pull request
Posté par M.Poil (site web personnel) . Évalué à 1.
Merci à tous pour les éclaircissements !
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
# branches, branches, branches
Posté par Thom (site web personnel) . Évalué à 2.
Git, c'est assez personnel, mais dans l'idée un fonctionnement assez simple à respecter.
Le master tu n'y touches jamais directement. Tu prends une branches par fonctionnalités en cours développement, par personne.
Git checkout -b "nouvelle branches et tu vas dessus"
Tu fais tes modifications…
Pour éviter les problèmes, tu fais tout sur le même dossier, pas de un dossier pour une branche, sinon, c'est la merde. Pour ça, tu fais des
commit -am "ton message"
Avant de faire une quelconque pull-request, tu t'assures de ne pas être derrière le master si un collègue à déjà pousser, sinon, problème de merge => chiant voir très chiant.
git checkout master
git status
Si tu es à jour ça roule :
git push origin mabranche
-> pull-request de ta branches sur le master
Si tu n'es pas à jour
git pull origin master // ça passe toujours
git pull origin mabranches // ici potentiel problème, mais c'est à toi de les résoudre, tu t'assures juste d'envoyer un truc qui marche encore.
Une fois que tout est prêt, tu pousses sur ta branches
git push origin mabranche
-> pull-request de ta branches sur le master
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.