How you setup git branches for multiple build platforms?

We are using git for version control, and projects are multi-platforms (Windows/Mac/iOS/Android). Mobile builds only contain a part of the functions/scenes of the projects, while Standalone builds contain all.

I was wondering how should I setup the git branches, so that, e.g., I open a Windows branch and able to build for Windows straight away.

Or, I should use git submodules that contain the common parts and keep the standalone project and mobile project separated?

Or, git is not really for that and I should just simply use platform-defines?

Most of the time I would run with platform defines and platform specific asset bundles. That should cover off most standard use cases.

2 Likes

Don’t use branches, merging updates to scenes will be a nightmare.

Platform directives are the way to go and I’ve never had problems.

4 Likes

We use VSTS you select a branch and you can send it to be built. Though we only have one platform, but it was alot of work getting the project to a level were build process is automated, with lightmap baking, etc, etc

If you want to quickly build to several platforms, you’ll need to have several copies of the project, one for each platform. Otherwise you’ll spend a LOT of time waiting for reimports.

The git setup here is that you have one “main” working folder that contains the project checked out to build to your current platform, and one work folder for each of the other platforms. The only difference for the other platforms is that their target platform and #define files are different.

Each of these working folders is a unique checkout of the same git repo. You can also use work trees for this - I haven’t done that, but my coworker that was handling way more plaforms at the same time did and found it useful. Anyway, you do your work in your main repo folder, then when you need to build to eg. PS4, you merge the main changes into the PS4 repo, open the PS4 repo, and build.

This costs disk space, but that’s pretty much free. What you save is hours and hours of waiting for the project to get reimported to each platform you need to build to.

Of course, a (better) alternative is to use a build server that does these things for you - either set up your own or try the one Unity offers. There’s some overhead to doing that, though. You’ll also still need to open the project locally to check things like if shaders are working in that specific platform’s flavour of OpenGL or whatnot, so even with a build server, you’ll want to have the copies of the project locally.

2 Likes

Thats what we are doing, we use the the branch name for location so that Libray folder stays intact between builds. Also the GI cache is kept intact so most overhead of building lightmaps is removed, though it would be cool to find a way not to build lightmaps if scene hasnt changed, probably possible with some playing around with build definitions. We also run the automated tests. If the tests fail you can not pull the branch into master

Cloud build? It’s seriously awesome.

https://docs.unity3d.com/Manual/CacheServer.html

1 Like

LOL you do know Unity has the Cache Server right?

For a large project (many GB of assets) it still takes half an hour to reimport to a new platform with the cache server. Unless the newer version is a very large improvement?

Do you have a decent SSD? That sounds ridiculously long.

This experience mirrors mine on SSD.

Mine, too.

I’m on a Samsung 960 PRO nvme disk. Our library folder is 19,6 and the game in total is 52 gigs. Havent clocked it but a reimport takes time, 30 mins sound reasonable.