Bonjour,

je suis un développeur junior et on m'a donné la responsabilité de mettre en place un environnement de travail en équipe sur GitHub (version gratuite si possible).

Je suis parti sur un design simple:

Tout ce passe bien si user1 travail sur une version à jour du repo de production mais dès qu'entre temps user2 a fait un push vers Repo Production, en essayant de faire un push sur repo Production je me retrouve avec des conflits. Des conflits qui des fois sont facile à corriger mais des fois Github dit que c'est trop complexe.

Le but est que ça facilite le travail en permettant de revenir en arrière mais certainement pas de devoir corriger des conflits à longueur de journée:

Je me dis que probablement j'ai mal-configuré le truc.

Alors quel architecture faut il mettre en place pour éviter les conflits sans se prendre la tête?

Merci!

-
Edité par kamoba 2 juin 2019 à 5:42:21

Pourquoi travailler sur 3 repos et pas plutot sur plusieurs branches d'un même repo ? (la branche master qui est considéré comme la version stable, une branche dev qui est considéré comme une branche qui deviendra une version stable et après plusieurs branches feature ou chaque utilisateur pourra coder puis merge dans dev)

J'avais intégré des branches dans mon design mais je trouvais qu'il compliquais les chose pour rien, alors j'aurais dû enlever les fork à la place.

Ok @r00tKiller merci, je suis partis sur ton idée et apparemment de manière absolu il y a pas moyen d'éviter les conflits.

J'essaye d’élaborer une méthode de travail pour palier ce problème (équipe de deux personnes):

Beta User (moi):

1. pull dev pour avoir la version à jour.

2. ajouter mes modif et faire un commit (bien que j'ai la possibilité de faire un push moi même, pas moyen de restreindre en free account et privé).

3. faire un pull request.

Alfa User:

1. Verifier si s'il n'y a pas de conflit entre dev et la branche de Beta User

2. merger et faire un push (accepter la pull request).

3. commiter ses propres modif, merger et push.

Je ne suis pas satisfait car je cherche un moyen moins laborieux, d'ailleurs j'ai fini par passer en ligne de commande qui est vachement plus pratique que je ne pensais.

Je vois souvent conseiller faire Rebase dans le processus mais j'avoue je ne comprends trop ce que ça fait et à qu'elle moment l'utiliser.

Des idées pour améliorer?

-
Edité par kamoba 4 juin 2019 à 4:26:28

Bonjour,

Comme le dit r00tKiller il faut que chaque dev fasse une nouvelle branche par fonctionnalité et fasse une merge request sur la dev.

Pour s'assurer qu'il n'y a aucun conflit entre la nouvelle branche et la dev, le développeur en charge de la nouvelle branche doit:

1- Pull la dev

2- Retourner sur sa branche et faire un git rebase dev

S'il y a des conflits pendant le rebase, il faut les corriger et les valider avec git rebase --continue.

Sinon il n'y a aucun conflit entre les 2 branches, dans ce cas le dev peut push son code sur sa branche et faire une merge request vers la dev.

Le rebase permet de mettre les commits de la branche dev en dessous des commits de la nouvelle branche.

Cela permet de gérer les conflits directement dans la branche plutôt que tester la dev après avoir mergé dessus.

-
Edité par eclairia 5 juin 2019 à 12:43:19

Salut eclairia,

J'ai commencé avec un truct comme ça mais les conflits m’agace.

Alors j'ai crée une ligne directrice qui permet pour l'instant (toujours en test) d'éviter les conflits en donnant toujours une priorité à une branche selon la situation.

Je partagerai mes commandes quand j'airai fini, mais il semble bien marcher.