5.4Teamwork: GDS (source manager)
The essentials in 30 seconds
- The GDS stores sources in a shared repository: each developer checks out an element to modify it, then checks it back in, with a full history.
- The GDS is useful even solo: rollback, an extra backup and traceability of decisions, far beyond simple dated copies.
- The team follows rules: check in often, comment, test, respect conventions and communicate before any change to the analysis.
Running mini-case — Yacine organizes his team's work with the GDS
Yacine develops the application for an electrical equipment trading SME in Oran. Samir works on the web portal and Nadia on the mobile application: all three share the same analysis and the same business procedures. Yacine puts the project under GDS and creates a common repository. Each person checks out the elements they are working on, tests them, then checks them back in with a precise comment. At noon, Samir and Yacine have modified the same discount calculation procedure: the GDS shows the history and allows a merge without overwriting the other's work. Before touching the Item file, Yacine warns the team, because an analysis change impacts everyone. He also backs up the repository, which has become the project's most valuable asset.
Standalone case for this section: it returns in the course, the diagram, the code and the 48h challenge of section 5.4.
1. The repository and the cycle
The GDS (Source Manager) is built into the WinDev workshop. Project elements are stored in a shared repository. Each developer checks out the elements they are working on, which takes them under their control, then checks them back in once modified and tested. This cycle prevents two people from overwriting each other's work. The GDS keeps the full history: who changed what, when, and with which comment. You can therefore understand an old decision or return to a previous version. This is far superior to folder copies named “project_final_OK”.
2. Useful even alone
The GDS is not reserved for teams. Even alone, Yacine gains a rollback after a mistake, a backup separate from his working folder and traceability of his decisions. He dares to experiment with a redesign or an optimization because he knows he can go back. Dated copies, on the other hand, say neither who did what nor why, and eventually become impossible to untangle. The GDS also imposes a useful discipline: check in in coherent steps and comment on what you have done.
3. Team rules
In a team, the tool is not enough: rules must be respected. Check in often (ideally every day) so you do not block colleagues. Comment usefully on each check-in: “fix to the key-account discount calculation” rather than “changes”. Test before checking in so you do not break the shared project. Define common naming and style conventions. And above all communicate before modifying the analysis, because the data model is shared and impacts everyone. Finally, back up the repository itself: it now concentrates the essentials of the project.
🔎 Concrete example — 🔎 Concrete example — A commented check-in
Yacine fixes the key-account discount and documents his change:
// Calcul de la remise accordée à un client
// GDS : réintégration commentée — seuil grands comptes corrigé
PROCEDURE CalculeRemiseClient(nCA est un réel) : réel
SI nCA >= 500000 ALORS
RENVOYER 5
FIN
RENVOYER 0Result: the history explains why the threshold exists, not just the diff.
Reflex: comment the check-in with the business reason and impact, not “changes”.
Section vocabulary
- GDS
- Source Manager built into WinDev: shared repository, checkout/check-in and history.
Simple example: Yacine puts the management project under GDS with Samir and Nadia.
What it is not: exchanging folders by USB stick with no history.
Reflex: GDS = versioned and shared sources.
- Repository
- Central store of project elements, separate from each developer's working folder.
Simple example: The repository contains the shared analysis and procedures.
What it is not: each person working on an isolated copy of the project.
Reflex: the repository is the asset to back up.
- Checkout / check-in
- Work cycle: take an element under control to modify it, then put it back into the repository.
Simple example: Nadia checks out the stock procedure, tests it and checks it back in.
What it is not: keeping an element checked out for weeks.
Reflex: check in often so you do not block others.
- History
- Record of who modified what and when, with comments and the ability to roll back.
Simple example: Yacine recovers yesterday's version after a mistake.
What it is not: relying on copies named projet_final_OK.
Reflex: the history explains and repairs.
- Branch
- Parallel line of development allowing an evolution to be isolated before it is merged.
Simple example: Yacine prepares a stock redesign in a dedicated branch.
What it is not: developing a risky redesign directly on the shared line.
Reflex: a branch isolates, then merges.
In practice — In practice — Working with the GDS
- Put the project under GDS and create the repository, even if you work alone, for history and rollback.
- Adopt the cycle: check out the element to modify, work, test, then check in quickly while commenting on what was done and why.
- In a team, define common conventions (naming, style, organization) and communicate before any change to the analysis.
- Back up the repository itself: it has become the project's most valuable asset.
Step-by-step script — testing before checking in (10 min)
Yacine checks the critical discount cases before putting the procedure back into the repository.
A quick test of business cases avoids breaking the shared project; you then check in with a precise comment.
Copy-paste template — my check-in comment
// Réintégration GDS — Yacine — 12/03
// Élément : PROCEDURE CalculeRemiseClient
// Modification : seuil grands comptes porté à 500 000 DZD
// Tests : remise 5 % à 600 000, 0 % à 100 000 → OK
// Impact analyse : aucun
// Règle : réintégrer souvent, commenter, tester, prévenirSolo work
Yacine uses the GDS alone to roll back after a risky redesign.
Web and mobile team
Samir and Nadia each check out their elements and check them in without overwriting the other.
Analysis change
Yacine warns the team before changing the Item file.
Trial branch
Yacine isolates a new version of stock in a branch before merging.
✓ Best practices
- Check in often and release unused elements.
- Comment and test each check-in.
- Communicate before any change to the analysis.
✗ Common pitfalls
- Keeping an element checked out for weeks.
- Writing “changes” as a check-in comment.
- Modifying the analysis without warning the team.
Key takeaways
- The GDS stores sources in a shared repository, with checkout and check-in.
- The history shows who, what and when, and allows rollback.
- The GDS is useful even alone: rollback, backup, traceability.
- In a team: check in often, comment, test, shared conventions and communication about the analysis.
48h challenge — apply it tomorrow
Like Yacine, put a project under GDS and complete a full cycle: check out a procedure, modify it, test it, then check it back in with a comment that explains the business reason and impact. Then cause a mistake and return to the previous version from the history. Back up the repository.
- I can explain the role of the repository and the checkout/check-in cycle.
- I know why the GDS is useful even solo.
- I know the team rules: comment, test, communicate about the analysis.
Frequently asked questions
Is the GDS useful when developing alone?
Yes, clearly. Even without a team, it provides history and rollback after a mistake, an extra backup separate from the working folder and traceability of decisions. It also allows you to experiment with peace of mind: you dare to redesign because you know you can go back. Dated folder copies say neither who, nor what, nor why, and you forget to make them at critical moments. For Yacine, the GDS is therefore useful even before Samir and Nadia arrive.
What rules should be adopted to work as a team on a WinDev project?
Simple but respected rules: check in often, ideally every day or at each coherent step; check out only what you need; comment usefully on each check-in; test before putting an element back into the repository; regularly retrieve other people's changes. On the code side, define common naming and style conventions, and avoid putting business logic in buttons. On the communication side, warn before any change to the analysis, because it impacts the whole team. Finally, back up the repository itself.
What is the GDS for even when Yacine develops alone?