Construct's project folder structure
Since you'll be dealing with individual files in the project folder, it's worth knowing how it's structured and what each folder and file is for.
In Construct 2
This is the overall project folder structure used in Construct 2:
First, the main project file is a .caproj file (really just an XML file) in the root. The .uistate file is another XML file that separately stores the user interface state, like which tabs are currently open. This is stored in a separate file because typically you do not want to share it. Having to log a change for the rest of the team just because you switched a tab is unnecessary and a possible source of problems, so Construct 2 deliberately saves this separately so you can exclude it. Basically, the file is for you only and is of no interest to the rest of the team.
The Animations folder stores Sprite object animations. Each Sprite object type has a subfolder with its name, and within that is another folder with the animation names, and then within that is a numbered sequence of PNG files for each frame of the animation (zero-based, as usual). For example, a Sprite named "Enemy" with a single animation called "Default" with 3 frames would have the following files:
\Animations\Enemy\Default\000.png
\Animations\Enemy\Default\001.png
\Animations\Enemy\Default\002.png
Note that if you add, remove or rename objects, animations or frames, the files and folders in the project folder update accordingly.
The Event sheets folder stores an XML file for each event sheet. As with the main project, each event sheet also has a .uistate file that shouldn't be shared. No subfolders are created in the project folder even if you arrange event sheets in to subfolders in Construct 2. Also note if you rename an event sheet, its corresponding files will be renamed.
The Layouts folder works very similarly to the Event sheets folder; it's simply a flat list of an XML file per layout, with a .uistate file that shouldn't be shared.
The Textures folder stores images for objects which have images but not animations, like the Tiled Background object. Each object has a PNG file for its image in this folder, e.g. TiledBackground.png. Note if you rename the object, the image file is also renamed.
Finally the Files folder stores all other project files, such as sound and music files, and any other imported project files.
In Construct 3
Construct 3 uses largely the same approach, but with a few differences. The main difference is project data files are JSON files (.json) instead of XML. Also some of the folder names are different, such as using a single images folder for all object images. None of this should affect how you use source control though, it's essentially the same data but in a slightly different format.
Source control basics
The image below shows the basic architecture of a source control system:
The server has the master copy of the project. This is the version with everyone's changes merged in to one place.
The clients have their own independent copies of the project, called their working copy. This means each team member's changes don't immediately affect the server, nor can other team members immediately see what they've changed. If a team member has finished a unit of work and wants to merge their changes in, they commit the changes to the server and their work is merged in. Once the changes are in the server's copy of the project, other team members can update to download any new changes to their own working copy.
A typical workflow in a single work session might be:
1. First update so you the latest version of the project
2. Make some changes
3. When done, commit the changes to the server
After committing, the next time each team member updates they will receive those changes from the server.
If you make changes then Update without committing, your changes will be reversed and overwritten with the server's copy. Usually the source control system warns you before this happens.
The main problem with this process is conflicts: when two people change the same part of a project at the same time then commit. The first person can commit the changes OK, but when the second person commits, the server will notice their changes conflict with the previous change and prevent them committing. They will have to first update again, merge in the other changes (or simply overwrite their own changes), then commit again. This will be described in more detail later on. If everyone only works on separate parts of the project, or at least co-ordinates to ensure two people don't change the same thing at the same time, you should be able to avoid most conflicts.
Note the server can be, and often is, actually on a team member's computer. In this case, there is still a separate copy of the project on their computer for the server, therefore the whole process still applies equally for that team member - they just happen to also be running the server. Team members can then connect over a local area network, which means no extra equipment is necessary, but then they can't commit or update if the server computer is switched off. Alternatively a dedicated always-on system can be set up to run the server, or you can host servers over the Internet.