Collaborative editing

Multiple people can work on the same Silex site using GitLab's collaboration features. Each publish creates a Git commit, so you get version history and conflict handling for free.

Two things to remember:

• Each collaborator needs their own GitLab account and access to the project.
• Publish often. Smaller, frequent publishes are easier to merge than large, infrequent ones.

Inviting collaborators

1. Open your project on GitLab (the link is in Silex's publish dialog)
2. Go to Settings → Members
3. Click Invite members
4. Enter their GitLab username or email
5. Choose a role:

Role	Can edit in Silex	Can publish	Can change settings
Guest	No	No	No
Reporter	View only	No	No
Developer	Yes	Yes	No
Maintainer	Yes	Yes	Yes

For most collaborators, Developer is the right role — they can edit and publish but can't change project settings.

How collaboration works with Git

Every time someone publishes from Silex, their changes are saved as a commit in GitLab. This means:

• You can see who changed what and when (GitLab → Repository → Commits)
• You can revert to any previous version if something breaks
• If two people publish changes to different parts of the site, Git merges them automatically

What happens if two people edit at the same time

If two collaborators edit the same site and both publish:

1. The first person's publish succeeds normally
2. The second person's publish also succeeds — Git merges the changes if they touched different parts of the site
3. If both people edited the same element, a merge conflict may occur. GitLab will flag this in the repository.

To resolve a conflict:

1. Open the project on GitLab
2. Go to Repository → Merge requests (or check the Commits page for conflict markers)
3. Choose which version to keep
4. The next publish from Silex will include the resolved version

Best practices

• Communicate. Let your team know when you're working on a specific page so you don't edit the same elements simultaneously.
• Publish often. Small commits are easy to merge. Large commits that change everything are conflict magnets.
• Use page assignments. If your site has 5 pages, assign one person per page to avoid overlaps.
• Review changes in GitLab. Before publishing, check GitLab's commit history to see what others have changed since your last edit.
• Don't edit the same Symbol simultaneously. Since Symbols sync across pages, two people editing the same Symbol is the most likely source of conflicts.

Using merge requests for review

For teams that want a review process before changes go live:

1. Create a branch in GitLab for each collaborator or feature
2. Each person publishes to their branch (configure the storage connector to use a specific branch)
3. When ready, create a Merge Request on GitLab
4. A reviewer checks the changes and approves
5. Merge into the main branch — the CI/CD pipeline rebuilds and deploys

This workflow is optional but recommended for larger teams or client projects where quality control matters.

Common mistakes

• Not checking who else is editing. Open GitLab's commit history before you start a session.
• Making huge changes in one publish. Break your work into logical pieces and publish each one.
• Ignoring merge conflicts. They don't resolve themselves — check GitLab when a publish seems off.

Learn more

• Publish to GitLab — the full publishing guide
• How publishing works — understanding the build pipeline
• GitLab collaboration docs — inviting members and managing roles
• Forkable Websites and Templates — vote for one-click forking of sites
• Version Control — vote for built-in version history

---

Quiz

Q1: You want a colleague to edit the site but not change project settings. What role should you assign?

• A) Guest
• B) Developer
• C) Maintainer

Answer

B) Developer — they can edit and publish but cannot change project settings like members or CI/CD configuration.

Q2: Two people edited different pages and both published. What happens?

• A) The second publish fails
• B) Git merges both changes automatically
• C) The first person's changes are lost

Answer

B) Git merges both changes automatically — Git can merge changes to different files without conflict.

Q3: You notice something looks wrong on the live site after a colleague published. How do you check what changed?

• A) Ask your colleague what they did
• B) Check GitLab → Repository → Commits to see the exact changes
• C) Republish your version to overwrite theirs

Answer

B) Check GitLab → Repository → Commits — every publish creates a commit with a full diff of what changed. You can also revert to a previous commit if needed.