We can modify content in the library and also in the project.We can have two repositories, link them together and work in both of them.Unity says: You are trying to import an asset which contains a global game manager.If we check in lib1 we can see the modification in the origin.We commit that and we are done in proj1.Going back to proj1/lib1 we see the submodule has changed.The change becomes visible in proj1 lib1 submodule.changed lib1_file.txt in proj1/lib1 folder.Use case 2: modify a file in proj1/lib1.Now we have the modified file in the origin as well.This makes sense as our pull changed the commit-pointer we have in proj1. this changed the proje1/lib1 submodule.opening the project proj1/lib1 shows that we can pull a change.Use case 1: modify a file in lib1 (the lib project itself not in the submodule).We commit the changes to the remote as well.Now we add lib1 to proj1, however this time the remote repo.We combine the projects by setting up the remote repository.We create the counter parts on a remote git.Generate the following structure: Lib1 // with remote origin Then basically check if we get around the issue of Test 1. Test 2: Link library project into the project’s asset folder (with remotes) ApproachĬreate proj1, lib1 and create a remote repository for both of them. For submodules we need an remote-origin.I cannot write changes from proj1/lib1 to lib1 (commit: yes, pull: no).I can make changes in the lib1 project.I don’t really get it, but what I get that it is related to the fact that I don’t use a remote origin. Reading the error message it’s because the origin is a bare repository.I can commit the change in proj1/lib1, in the submodule.The change is also visible in proj1/lib1, in the submodule.The change is visible in proj1 (submodule changed).Let’s see if we can get that into proj1/lib1.Use case: modify a file in lib1 (the lib project itself not in the submodule).Let’s see how this setup works and do some tests. I incidentally unstaged them and created an incompatible state and I had to setup everything again. Never unstage the initial submodule files. Now the library project is part of proj1.īe careful: If you create a submodule in Sourcetree it automatically stages the files for you. Two modified files appear in proj1 (they are already staged)īasically that’s it.Set local relative path (in proj1): Asssets/lib1.Source Path: Navigate to the root folder of lib1.Right-Click on submodules -> Add Submodule.The next step is to link lib1 into the main project. Now we have two repos with one commit in each. Then we need to create the repositories in each folder. To set this up we first create the project structure. The result should look something like this: Lib1 Then I like to inject lib1 as a submodule into proj1: The initial structure looks like this: Lib1įirst I want each project to be in it’s own repository. ![]() In this approach I like to see if I can simply link the library project as a sub-folder into the Assets folder of the product project.īeing lazy I try this without using a remote git-repo. The test case is made of one product project and one library project. Test 1: Link library project into the projects asset folder (no remotes) Approach ![]() ![]() As I had several ways in mind how I could solve this I took the liberty to write down my approaches and share them here. To use this model one has to solve one issue: Unity (in it’s current state) forces the game creator to put all source-codes and assets into one folder named: Assets. All this without Unity plugins or the need of none-git work before or after the code change. So if I check out an old commit of a product it shall checkout the matching library project commit as well. Also I want to have reproducible connections between the project and the library code. The development model I have in mind looks like this: I like to have on or more product project sharing one or more library project and want to able to commit, push and pull in each of them. In this article I share my notes on my experiments around git submodules in Unity projects. Submodules can be a great tool for sharing library code and I like to make use of them when working with Unity. Use the new Unity PackageManager features?ĭoesn’t work: Complicated and doesn’t work with older Unity versions Link the library project into the project’s Assets folder with remotes repo?ĭoesn’t work: Unity doesn’t like a complete sub-project in the Assets folder.ĭoesn’t work: Subtree is more or less an import and not a link. Link the library project into the project’s Assets folder, without remote git repo?ĭoesn’t work: For submodules we need a remote-origin
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |