Aller au contenu

Édition collaborative

Plusieurs personnes peuvent travailler sur le même site Silex grâce aux fonctionnalités de collaboration de GitLab. Chaque publication crée un commit Git, vous bénéficiez donc gratuitement de l'historique des versions et de la gestion des conflits.

Deux points à retenir :

  • Chaque collaborateur a besoin de son propre compte GitLab et d'un accès au projet.
  • Publiez souvent. Des publications petites et fréquentes sont plus faciles à fusionner que des publications volumineuses et espacées.

Inviter des collaborateurs

  1. Ouvrez votre projet sur GitLab (le lien se trouve dans la boîte de dialogue de publication de Silex)
  2. Rendez-vous dans Settings → Members
  3. Cliquez sur Invite members
  4. Entrez le nom d'utilisateur GitLab ou l'email du collaborateur
  5. Choisissez un rôle :
Rôle Peut éditer dans Silex Peut publier Peut modifier les paramètres
Guest Non Non Non
Reporter Consultation uniquement Non Non
Developer Oui Oui Non
Maintainer Oui Oui Oui

Pour la plupart des collaborateurs, Developer est le rôle approprié — ils peuvent éditer et publier mais ne peuvent pas modifier les paramètres du projet.

Comment la collaboration fonctionne avec Git

Chaque fois que quelqu'un publie depuis Silex, ses modifications sont enregistrées sous forme de commit dans GitLab. Cela signifie :

  • Vous pouvez voir qui a modifié quoi et quand (GitLab → Repository → Commits)
  • Vous pouvez revenir à n'importe quelle version précédente si quelque chose ne fonctionne plus
  • Si deux personnes publient des modifications sur des parties différentes du site, Git les fusionne automatiquement

Que se passe-t-il si deux personnes éditent en même temps

Si deux collaborateurs éditent le même site et publient tous les deux :

  1. La publication de la première personne réussit normalement
  2. La publication de la seconde personne réussit également — Git fusionne les modifications si elles portent sur des parties différentes du site
  3. Si les deux personnes ont modifié le même élément, un conflit de fusion peut survenir. GitLab le signalera dans le dépôt.

Pour résoudre un conflit :

  1. Ouvrez le projet sur GitLab
  2. Rendez-vous dans Repository → Merge requests (ou consultez la page Commits pour les marqueurs de conflit)
  3. Choisissez quelle version conserver
  4. La prochaine publication depuis Silex inclura la version résolue

Bonnes pratiques

  • Communiquez. Informez votre équipe lorsque vous travaillez sur une page spécifique pour éviter de modifier les mêmes éléments simultanément.
  • Publiez souvent. Les petits commits sont faciles à fusionner. Les gros commits qui modifient tout sont des aimants à conflits.
  • Utilisez des attributions par page. Si votre site a 5 pages, assignez une personne par page pour éviter les chevauchements.
  • Consultez les modifications dans GitLab. Avant de publier, consultez l'historique des commits de GitLab pour voir ce que les autres ont modifié depuis votre dernière édition.
  • Ne modifiez pas le même Symbole simultanément. Comme les Symboles se synchronisent entre les pages, deux personnes modifiant le même Symbole est la source de conflits la plus probable.

Utiliser les merge requests pour la revue

Pour les équipes qui souhaitent un processus de revue avant la mise en ligne :

  1. Créez une branche dans GitLab pour chaque collaborateur ou fonctionnalité
  2. Chaque personne publie sur sa branche (configurez le connecteur de stockage pour utiliser une branche spécifique)
  3. Lorsque c'est prêt, créez une Merge Request sur GitLab
  4. Un réviseur vérifie les modifications et approuve
  5. Fusionnez dans la branche principale — le pipeline CI/CD reconstruit et déploie

Ce workflow est optionnel mais recommandé pour les équipes plus importantes ou les projets clients où le contrôle qualité est important.

Erreurs courantes

  • Ne pas vérifier qui d'autre est en train d'éditer. Consultez l'historique des commits de GitLab avant de commencer une session.
  • Faire d'énormes modifications en une seule publication. Découpez votre travail en parties logiques et publiez chacune séparément.
  • Ignorer les conflits de fusion. Ils ne se résolvent pas tout seuls — vérifiez GitLab quand une publication semble anormale.

En savoir plus

Quiz

Q1 : Vous souhaitez qu'un collègue puisse éditer le site mais pas modifier les paramètres du projet. Quel rôle devez-vous lui attribuer ?

  • A) Guest
  • B) Developer
  • C) Maintainer
Réponse

B) Developer — il peut éditer et publier mais ne peut pas modifier les paramètres du projet comme les membres ou la configuration CI/CD.

Q2 : Deux personnes ont modifié des pages différentes et ont toutes les deux publié. Que se passe-t-il ?

  • A) La seconde publication échoue
  • B) Git fusionne automatiquement les deux modifications
  • C) Les modifications de la première personne sont perdues
Réponse

B) Git fusionne automatiquement les deux modifications — Git peut fusionner des modifications portant sur des fichiers différents sans conflit.

Q3 : Vous remarquez que quelque chose ne va pas sur le site en ligne après qu'un collègue a publié. Comment vérifier ce qui a changé ?

  • A) Demander à votre collègue ce qu'il a fait
  • B) Consulter GitLab → Repository → Commits pour voir les modifications exactes
  • C) Republier votre version pour écraser la sienne
Réponse

B) Consulter GitLab → Repository → Commits — chaque publication crée un commit avec un diff complet de ce qui a changé. Vous pouvez également revenir à un commit précédent si nécessaire.

Éditer cette page sur GitLab