The Git Workflow
CodeKit is designed to work well with Git. Here's how it should go:
- One person adds the project folder to CodeKit and configures initial options like default language settings and default output paths.
- Once the project is configured, commit everything INCLUDING the config.codekit3 file to your repository.
- Other team members should now clone the repo and add the project to CodeKit on their Mac.
- CodeKit reads the config.codekit3 file and uses those settings.
- Each person commits their work AND their settings file to the repo.
- If there are conflicts, the settings file is simple JSON so you can see diffs and resolve the issues just like you do for any other file.
The Initial Setup Is Key
Step #1 is important. Configuring most of your Project Settings at the beginning will save you headaches later on because it vastly reduces the chances of having a conflict when you commit the config.codekit3 file.
WARNING: Pause Before Pulling!
Make sure you read CodeKit + Git!
You must pause CodeKit's file-watching before performing any Git action that changes multiple files at once (like a pull). If you forget, your file settings may get changed randomly!
The "Shared Disk" Workflow
In this scenario, your team works from a shared disk. Each developer connects to that disk and adds the same folder to CodeKit on their Mac.
Whenever one person changes a setting, CodeKit will update the config.codekit3 file. When that happens, the other copies of CodeKit on everyone else's Macs will notice that change and update to reflect the new settings.
This process works, but it can be fragile. First, everyone MUST have a rock-solid connection with low latency. If the connection is poor or laggy, CodeKit can't keep up with changes as they happen and the result is unpredictable. This is NOT a workflow to be used remotely; all of your developers and your shared disk must be on the same local area network.
Secondly, if multiple people change settings at the same time or in very quick succession, some settings may not be applied because they're trumped by others. The same guideline applies here: configure your project at the outset so that you don't have to change many settings as you work!