• In your source control of choice, exclude the folders Library, Temp, obj as they are not needed to open the project on another computer and would just clutter the repository and use storage needlessly
• In the Unity Editor, go to Edit > Project Settings > Editor and set:
• Version Control to Visible Meta Files: This will place meta files next to your assets, in which parameters and import settings are stored. This allows you to share import settings and references by including these files in version control. Otherwise, these settings are stored in the Library folder and cannot be shared between members of the team.
• Asset Serialization to Force Text: make all unity files (ScriptableObjects, Scenes, Prefabs and many others) use a text representation instead of a binary one. This allows source control to just store modifications to these files when they change, rather than a whole new copy of the file, and allows you to manually merge any conflicts (Note : on very big projects, the additional time needed to import text asset versus binary asset could create a quite noticeable difference. Most projects will not reach that size threshold where the benefits of text over binary are overcome by time of import, so setting to text in the beginning is still recommended)
• Note for Perforce Users: In the Perforce Workspace settings, use "revert unchanged files". This will prevent unnecessary commits of files that have not changed.

• Units : decide what one unit in Unity is, otherwise models or sprites will not be created using a unified scale. Introducing different scaling for different objects can lead to all sort of problems.
• For most 3D games that use Rigidbody components, use one unit = one meter, as the physics system requires that for proper simulation
• For 2D games that use Rigidbody components, define a "base sprite size" that will be equal to one meter and one unit. For example 32px = 1 meter and 1 unit. Set all Sprites Pixel Per Unit to that value, so your character sprite that is 64px tall, with a PPU of 32 will be two units therefore two meters tall for the physics system.
• Naming: your assets should all follow a naming convention. It can be appending suffixes (An example for textures would be N for normal map or _AO for Ambient Occlusion map) or prefixes (Such as LowRes or HighRes_ on variations) . It will allow to filter through search and also can help writing custom importer setting value automatically.

• A folder for each type of asset and subfolders in them per objects, zones (For example Assets/Materials, Assets/Prefabs, with subfolders Assets/Material/Level1 or Assets/Prefabs/Enemies)
• A folder per objects or zones (Such as Assets/Level1/Enemies/Archer, Assets/Shared/UI, Assets/Forest/Trees) with all assets related to those in the folders (Assets/Forest/Trees/BigTree.fbx, Assets/Forest/Trees/Tree.mat, Assets/Forest/Trees/Tree_Bark.jpg).

[MenuItem("Tools/Check Prototype References")]
static void CheckprototypeReferences()
{
    string prototypePath = EditorUtility.OpenFolderPanel("Choose folder", Application.dataPath, "");

    if (prototypePath != "")
    {
        var files = System.IO.Directory.GetFiles(prototypePath, "*.*", System.IO.SearchOption.AllDirectories);

        //make it relative to asset folder so we can compare easily later
        prototypePath = prototypePath.Replace(Application.dataPath, "Assets");

        foreach (var s in files)
        {
            string relativePath = s.Replace(Application.dataPath, "Assets");

            //ignore metafile
            if (!relativePath.EndsWith(".prefab") && !relativePath.EndsWith(".asset"))
                continue;

            var assets = AssetDatabase.LoadAllAssetsAtPath(relativePath);

            foreach (var a in assets)
            {
                SerializedObject obj = new SerializedObject(a);
                var prop = obj.GetIterator();

                while(prop.NextVisible(true))
                {
                    //monobehaviour have exposed Icon & script we do not want to test
                    if (prop.propertyType == SerializedPropertyType.ObjectReference 
                        && prop.displayName != "Icon" && prop.displayName != "Script")
                    {
                        var referencedAssetPath = AssetDatabase.GetAssetPath(prop.objectReferenceValue);

                        //ignore built-in resources, only look if we are linking stuff from the projects
                        if (!referencedAssetPath.Contains("Assets/"))
                            continue;

                        if(!referencedAssetPath.Contains(prototypePath))
                        {
                            Debug.Log("External referenced on " + relativePath + ": " + prop.displayName + " to " + referencedAssetPath, a);
                        }
                    }
                }
            }
        }
    }
}

• To use a direct reference (public variable in Monobehaviour) to assign through the editor. This will also support moving or renaming of files.
• If you really need or want to use Resources.Load, use the Resources.LoadAsync version of the function, which will not block execution (on some devices, Loading can take a long time). This function returns an AsyncOperation that you can either poll every update to check if it's finished, or use the completed event like this:

      ResourceRequest request = Resources.LoadAsync("cube");

      request.completed += operation =>

      {

          ResourceRequest op = operation as ResourceRequest;

          Instantiate(op.asset);

      };

• Those files are usually bigger than exported files. Bigger files lead to cluttering the source control history, and every time you modify one, the source control will store the new version, leading to an explosion of the size of your repository.
• Those files rely on the software they belong to being installed on the machine opening the Unity project. Any collaborator without the right software installed or a build machine will not be able to open the project.

• Do not nest pure gameplay objects with the graphics, physics & audio representation. If something does not need to move with your character, it should not be a child of it. For example, having a GameObject that handle the patrol points of a navmesh agent character is a child of that character. All pure gameplay GameObjects should be as close to the root as possible.
• Similarly, when you create a GameObject dynamically, do not make them a child of the object that created them unless they need to be moved with that object

• Use Optimize GameObject in the Rig tab of your Animation import settings. This will prevent the "skeleton" GameObject of your rig being created, reducing the hierarchy. If you need to still expose some (you may use one as the target to attach equipment on the character) you can manually pick it to only expose this one.

• Static functions that implement the cheat with <b> [MenuItem("Cheat/MyCheat")] </b> will allow you to cheat when playing in the editor through a top menu entry.
• Good old "Cheat code" based on key press in a particular order, or even simply using the F1/F2 function keys of your keyboard.
• Code an in-game console that can be opened with a keypress and in which commands can be typed & interpreted to cheat.

• A conditional attribute for cheat functions

[Condition(DEVELOPMENT_BUILD || UNITY_EDITOR)] 
void MyCheatFunc() 
{
 //your cheat goes there
}

• This allows the compiler to just ignore that function on non-development build, so calls to that function will just be ignored.
• Or wrap code related to cheating inside functions between

#if DEVELOPMENT_BUILD || UNITY_EDITOR
//Code related to cheating
#endif

• This ensures they will be stripped from the final build. Note, that if you wrap a function between those, the build will fail because all calls to that function will be calling a non-existent function for the compiler. It is preferable to use the Conditional attribute above for functions.