If you're using the shared development model, the Changed by column might list objects as changed by Unknown:

You can still commit the change to source control as normal, as the "Changed by" information is never committed to source control anyway.

Possible causes

The object type is unsupported

SQL Source Control can't tell who made changes to data, or to the following object types:

Information is lost from tempdb

By default, SQL Source Control reads information about who made changes from the default trace and saves it in tempdb. However, because tempdb is reset when the server is restarted, information about who made a change is eventually lost.

Fix

To stop the information being lost, you can create a database to log changes instead of tempdb.

SQL Source Control was updated while there were uncommitted changes

If you update to a new version of SQL Source Control while there are uncommitted changes, information about who made changes might be lost.

The object was renamed

When an object is renamed, information about who renamed it is lost.

This is because SQL Source Control reads information about who made a change from the default trace. In the case of a rename, the default trace records the activity correctly as a rename. However, SQL Source Control interprets the action only as a drop and create, and so can't find the relevant information in the default trace.

The default trace rolled over before SQL Source Control could poll it

When SQL Source Control checks the database for changes, it reads information about who made a change from the default trace and saves it in tempdb.

If you're working with a busy server, the default trace can fill up and roll over before SQL Source Control can read it. Information about who made changes is lost. 

To improve the chances of the default trace being read before it rolls over, you can set the change indicators to update more frequently in the Setup tab. However, this might slow down your server.

The default trace is disabled

When SQL Source Control checks the database for changes, it reads information about who made a change from the default trace. If the default trace isn't enabled for the server, information about who made the change is lost.

To enable the default trace, run this SQL:

EXEC sp_configure 'show advanced options', 1
RECONFIGURE
EXEC sp_configure 'default trace enabled', 1
RECONFIGURE

You don't have permission to access the default trace

When SQL Source Control checks the database for changes, it reads information about who made a change from the default trace. If you don't have the correct permissions to access the default trace, information about who made the change is lost. 

Users need the ALTER TRACE and VIEW SERVER STATE permissions to access the default trace. To add these permissions, your system administrator needs to go to each user's login (Security > Logins on the server level) and enable them under Securables.

The server timed out

If the server takes too long to respond, SQL Source Control can't tell who changed any objects. When this happens, SQL Source Control displays a warning bar above the change list:

Unlike other causes of the "Unknown" problem, missing information caused by a server timeout isn't lost permanently. To see who changed the object, try refreshing the change list when the server is less busy.