Discussion :

[Wilhem31]

Bonjour,

Je travaille actuellement sur un projet avec un autre développeur ( tout les deux débutants ) , et nous n'arrivons pas à faire un merge request sur Gitlab, c'est notre premiere fois ahah
Du coup je me permet de vous dérouler le scénario pour voir si vous voyez des erreurs que nous avons faites qui pourrait justifier ce probleme :

Début du projet : on part de mon repo branch master, mon collègue à fait un fork afin d'avoir une copie sur son repo, puis un git clone pour avoir le projet sur sa machine et à créer une branch pour dev sa partie. Jusque là je pense qu'on est bon, nous n'avons pas eu de soucis.

Moi de mon côté, je suis partie sur une nouvelle branch de features aussi, du coup aujourd'hui on a voulu réassembler notre travail, et c'est peut être de la que vient l'erreur?

Moi j'ai commencé par merge ma branch de features sur le master, puis j'ai fait un git push origin, enfin j'ai créer une nouvelle branch du même nom que celui de mon collègue pour " accueillir sa branch".
Il a donc de son coté fait un push de sa branch vers son repo, puis un merge request de sa branch vers la branche du même nom dans mon repo.

Le problème est que maintenant je me retrouve sur le merge request avec :



Donc il y a des conflits mais sans autre détails ni solutions ! J'ai essayé le merge locally, qui me propose de faire un fetch de sa branch mais je me trouve apres la commande avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ git fetch https://gitlab.com/user_gitab/<project>.git features/options
remote: The project you were looking for could not be found.
fatal: repository 'https://gitlab.com/user_gitab/<project>.git/' not found

Quelle est l'erreur ?? Est ce le fait que j'ai merge et push sur le repo qui amene les conflits ? Pourriez vous m'expliquer la façon de proceder typique dans le cas d'un merge request ?

Merci de votre retour.


Cordialement,

[Marco46]

Vous avez un premier problème à gérer qui est de définir quel modèle de collaboration vous choisissez, soit vous êtes en étoile, soit vous êtes en forking model.


En étoile :

Vous n'avez aucun fork, vous clonez tous directement le repo central.

Votre liste de remote ressemble à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ git remote -v
origin	https://<url-gitlab>/<nom-projet> (fetch)
origin	https://<url-gitlab>/<nom-projet> (push)

Vous mettez votre branche de collaboration (nommée aussi branche d'intégration des développements) qui s'appelle par défaut master mais qui peut s'appeler aussi develop ça dépend des conventions en protected. Ça signifie que vous ne pouvez pas pousser dessus directement, vous devez passer par une Merge Request.

Pour collaborer au projet il faut donner des accréditations à l'utilisateur (droits de lire, droits de push, etc ...).


Forking model :

C'est le modèle utilisé par l'open source. Par défaut toute personne souhaitant contribuer au projet crée un fork du repo central. Ensuite il clone son fork sur machine, et il ajoute un remote pour désigner le repo central.

Généralement je renomme origin en fork et je nomme le repo central en central ou en origin (puisque c'est la vraie origine) et ça donne ce genre de chose :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$ git remote -v
fork  https://<url-gitlab>/<nom-projet-fork> (fetch)
fork  https://<url-gitlab>/<nom-projet-fork> (push)
central  https://<url-gitlab>/<nom-projet-central> (fetch)
central  https://<url-gitlab>/<nom-projet-central> (push)

Une autre pratique consiste à changer seulement la fetch url pour la faire pointer sur le repo central ce qui donne alors :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ git remote -v
fork  https://<url-gitlab>/<nom-projet-fork> (push)
central  https://<url-gitlab>/<nom-projet-central> (fetch)

L'avantage du forking model est qu'on a pas besoin de gérer les accréditations sur le projet central puisque les contributeurs ne poussent jamais dessus. Ils ne font que lire depuis le repo central et écrivent sur leur fork qui sert ensuite de base pour effectuer une MR du fork vers le central. Ainsi le mainteneur du repo central peut faire le douanier tranquillou billou. Il ne gère les accréditations que pour les core contributors.

L'inconvénient c'est que ça prend beaucoup plus d'espace disque (un repo par utilisateur par projet + un repo central par projet).



Pour en revenir à votre problème, je pense que ton collègue à simplement fork ton projet à toi, et qu'il n'y a pas de repo central et qu'il n'a pas changé sa fetch url. Du coup il n'a pas tes modifications lors du merge et du coup vos historiques divergent.

Il faut donc déjà gérer ce problème de stratégie de collaboration, ensuite il y aura certainement d'autres questions sur quand merger et comment gérer ça

[Wilhem31]

Bonjour,

Déjà merci pour les explications sur les différents modèles de collaboration , c'est bon à savoir!

Du coup, il faudrait que mon collegue fasse pointer sa fetch url sur mon repo, afin d'avoir les modifications effectué lors de mon merge , qu'il refasse un push sur son repo pour avoir le même master que moi puis enfin une nouvelle merge request ?
Penses tu que cela foncitonnerait ?

Merci,

Cordialement,

[Marco46]

Non, soit vous pointez tous les deux sur le même repo, soit vous avez tous les deux un fork d'un repo central.