Adding collaborators
Your other team-mates also need to get access to your repository. You can add collaborators in the Settings section of your repository on the GitHub website. Note there may be limits depending on your account tier. For more details on inviting collaborators, see GitHub's help on Inviting collaborators to a personal repository.
Once you've invited a collaborator, they should also be able to access the repository on the GitHub website. Then the process is similar to when you first created the repository: download and install GitHub Desktop, then on the website click Clone or download, then Open in Desktop. As before they can choose a local folder to clone the repository to, and it'll download all the project files there. Then they're all set up to push and pull changes the same way you do.
Receiving other changes
You'll frequently want to receive any other changes made to the repository if you have other team-mates making changes.
All you need to do is click Pull origin (sometimes also shown as Fetch origin) in GitHub Desktop to pull any new changes back from the server to your local working copy. However whenever you do this, make sure you have closed your project in Construct. This will update your project files but Construct won't see that they've changed, and next time you press 'Save' you might revert the changes and end up with a mess. Making sure you've closed your project guarantees you won't accidentally overwrite anything, and ensures that when you next open it, Construct will reflect all the latest updates in the editor.
GitHub Desktop can also alert you if there are changes waiting to be pulled from the server, as shown below. Clicking Pull origin will receive those changes - but as noted be sure to make sure your Construct project is closed before doing that.
Thanks to the magic of source control, this will also merge changes with your own files. This is a key feature of source control. Providing you have not changed the same files in the same places, everything should just automatically merge in to a single coherent project.
Conflict resolution
What happens if two people do modify the same part of the same file at the same time? This creates a conflict.
Conflicts are something you should aim to avoid at all costs, since they can easily be complicated and confusing. You should avoid working on the same parts of the project at the same time wherever possible. However they can end up happening accidentally from time to time anyway.
As an example, suppose two people commit a change to the project description. One person changes it to "My awesome project!", commits it and pushes it to the server. Then a second person changes it to something different, like "My SUPER awesome project!", commits that, and attempts to push it to the server. GitHub Desktop will stop the second person pushing because it knows there are changes it hasn't received yet. So it will require you to pull first.
This is where the conflict happens. The second person sees a conflict because they have their own change to the project description, but they are trying to receive a different change to the project description. Which description is supposed to be there? This cannot be automatically resolved, so it has to ask you to fix it.
You will have to manually to resolve this. Often the easiest solution is to abort the merge, then revert your local changes. You can revert a commit in the History section.
However in some cases you will have a lot of changes and you don't want to lose all that work. So alternatively you can manually edit the file to resolve the conflict. The default suggestion is to use Visual Studio Code, a coding editor, to edit the file as text. (You'll need to download and install that first to use it.) It has special support for handling conflicts. In this case it opens the project file with the conflicting description in VS Code, and then if you scroll down it highlights the conflict and also provides options on how to resolve it:
If you know what you are doing, you can edit the text manually. However the easiest way to solve it is to click either:
- Accept Current Change: use the change you were trying to commit. Remember it's the second person who is resolving the conflict, so this means the second description is used, overwriting the first description.
- Accept Incoming Change: use the change from the repository. This means the first person's description is used, overwriting the second description.
In this case we'll do with Accept Current Change, so the second description is used. It's possible there will be other conflicts in the file too, so you may need to scroll through the file and fix them all. Once everything is resolved, save the file and close it. GitHub now identifies that there are no conflicts left, so now Commit merge is enabled and you can now continue to pull the changes from the repository.
Note the way GitHub handles this is it adds a second commit that deals with merging the conflict. Then you can finally push your change, and the project is updated on the server.
A good way to review what happened is to look at the commit history on the GitHub website. You can view a list of each commit in the order they were pushed, and see the differences in the files they changed.