Game Development Reference
In-Depth Information
3. Commit your change to your branch.
4. Submit a Pull Request (PR) from your repository back to the main branch of
the parent repository.
5. Monitor the request and answer queries.
6. If necessary update your development branch in your repository in answer
to queries/requests.
7. Commit your fixes (no need to create a new PR, it will automatically
be updated).
8.
Once accepted, delete your development branch.
9.
Refresh your repository from the parent.
Bitbucket has all this information to hand on their site, so check it regularly
for updates.
If you have already made your changes to your own repository (some developers
to have a playground where they test things), then do not fret. Simply create a new
branch in your source code application from the last
Commit
point by Unity, then
follow the previous steps and copy your change in.
It's quite normal to have a playground/sandbox area in your own
repository; just be sure to start from a new branch in your local project
before doing anything and above all else, keep the main development
branch (the one from Unity) clean.
Do not commit directly to the unity
main branch.
Always use a new/clean branch of your own, or things will get muddled.
Happy coding!
A last note about submitting changes in the current process. Unity won't
actually accept your change directly into their repository. The pattern
currently being followed is that Unity will review your change and if it's
deemed worthy they will copy your fixes/changes into their own code
servers for consumption.
So they aren't using the source control in a normal fashion; they're just
using it for people to highlight what they can easily fix/include. This may
change over time as Unity get better working with Bitbucket.
