Properly manage library of classes / categories for reuse by other git team developers

Question

Scenario. A team has 5 developers and all developers are working independantly on 4 different projects. iOS / OS X. A library has been created which encompasses multiple subclasses, categories and so on for reuse. Each member in this team needs to be able to use this library for each project. The library itself has it's own git repo. When someone makes a change to the library it is handled the same way a standard project is handled and a merge is completed.

Problem I see with this approach... 1. This doesn't seem like common practice for a proper Xcode / Git workflow and I feel a framework or similar would be a better tactic. 2. Although this is great for sharing I can also see this as an issue since one issue with the library will break all existing projects. 3. Adding classes to this library requires each project to be updated to include the new headers. 4. Directory structure can differ on each machine therefore a simple clone of a repo will not work as expected without folder modification.

What is the best way to handle your own library of classes in a Xcode / team environment of multiple users?

Answer 1

If you must have a single library for all this - you can go two ways:

1. Nobody changes the library, the library is as it is and everyone just pulls it down and then makes changes in their code to make-up for the shortcomings they find in the library.

2. Everyone changes the library, but the project has A master branch, a stage branch, and a branch for every single project associated with it. Devs change and update their respective project branch, and another person (perhaps one of the project devs maintains the flow from the multipe dev to the single stage to the single master branch). With this approach, it requires much more management but you can slowly improve the main library without potentially breaking other projects as everyone has their own specific know-to-work version of the library in a branch specific to their project, only re-syncing with the master when safe.