![]() * Get a team member to check over (buddy) your changes.įirst of all congratulations to this great demo!ġ. ![]() * Test that your changes work in the main branch. * Integrate your changes over to the main branch locally. * Make changes in your branch locally until you're happy with them. When submitting changes, the procedure would go something like: Each of us had our own branch and we had some scripts to assist with integrating our changes in and out of the main branch. We used Perforce for our source control - we made some little utilities to help integrate it into Unity but to be honest I think a SCM system that doesn't prefer you to check things out before you modify them works best with Unity. The problem with this approach was that it prevented us using prefabs as they were intended: building blocks from which you can build your scene from. We did have several occasions though where settings or work that someone did were lost because somebody forgot to apply a prefab or had accidentally made settings changes over the top of it. This only worked if the changes you were making on the prefab didn't contain references outside of the prefab, but it worked fairly well. However, if you were working on a section that had been made into a prefab, you could make your changes, apply the prefab, and check in the prefab only. We had a little model man made out of Lego, called 'The Main Man', which you had to have on your desk if you wanted to make changes in the main scene. ![]() Each prefab was used in one place in the file only. In our game we had a main scene file with reasonably large chunks of it made into prefabs. ![]()
0 Comments
Leave a Reply. |