---
sourceDocument: Australia Build or modify applications
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/application-development

 Release :

    - australia

ft:locale :

    - pt-BR

ft:publication_title :

    - Australia Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Legacy - Migrate completed update set history to Source Control

# Legacy - Migrate completed update set history to Source Control {#ariaid-title1}

* Versão de lançamento: Australia
* 
* Atualizado 12 de mar. de 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 min. de leitura

When linking to Source Control, this feature allows application developers the choice of
migrating the information in completed update sets to Source Control history.  
Importante:  
Starting with the Xanadu release, the legacy version of ServiceNow Studio is being prepared for future deprecation. It will be hidden and no longer activated on new instances but will continue to be supported. For details on the deprecation process, see the [Deprecation Process \[KB0867184\]](https://support.servicenow.com/kb_view.do?sysparm_article=KB0867184) article in the Now Support Knowledge Base.

Try building and editing apps in the current version of ServiceNow Studio instead. For more information, see [ServiceNow Studio](https://servicenow-prod.fluidtopics.net/HJE5fDsb~bjmVZ9BqGtS8w "ServiceNow Studio provides a unified experience for all ServiceNow development activities, enabling admins and developers to extend base system solutions and create custom apps with ease. Use ServiceNow Studio to build apps and app files with integrated tools, access and edit app metadata in scoped and global apps, and package app changes for deployment, all in one powerful development tool.").

## Before migrating {#migrate-update-set-history__section_qhw_h1p_rpb}

Make sure that you have fulfilled these criteria before attempting to migrate your update sets:

* Role required: admin
* Read the [Legacy - Link an application or application-customization to source control](https://servicenow-prod.fluidtopics.net/2oVB7fYJ7Iq7VapMevRcow "Linking an application or application-customization to source control allows application developers to manage changes from a Git repository.") topic
* Complete any update sets for your application that you want to export as Source Control history.
* Export the completed update set if you want to preserve it.
{#migrate-update-set-history__ul_ovk_31p_rpb}  
When you link an application to Source Control, the update sets and customer update records are deleted. After you link to Source Control, if the application has any completed update sets, you will be asked to make a choice in the dialog box below.

* If you select "Yes, do retain update set history as commits", the update set history is preserved as Source Control commits.
* If you select "No, do not retain update set history as commits," they are not preserved as commits.

{#migrate-update-set-history__ul_ez3_tsh_wpb} Regardless of which option you select, if you select Continue, the Link to Source Control operation starts, and all completed update sets and all Customer Update records are deleted. If you need to complete any additional update sets or choose not to continue, select Cancel. For every completed update set with updates to the application that you are linking to Source
Control, commits are generated automatically by the system based on the sys_update_xml records
in the update sets. The commits are ordered by the sys_recorded_at
timestamp. For Global applications: Any sys_update_xml records that
belong to the application and are part of a completed Global update set are captured as
historical commits.  
When the Link to Source Control operation is complete, the most recent commit is the current state of your application in its entirety. You can view historical commits in your Git repository or by clicking the Source Control menu option and selecting View History. Updates are separated into multiple commits:

* If there are updates for a file that are out of order between different update sets.
* If an update set contains multiple update records for a single file.
{#migrate-update-set-history__ul_m33_t1p_rpb}

The commits for an update set are split into multiple commits (\[Historical Commit 1\],
\[Historical Commit 2\]...) to represent each update. This is done so that each file has an
ordered history of updates.  
Aviso:  
Any commit prefixed by \[Historical Commit\] is generated solely to display its history. Do not attempt to check out these commits in the development process as they do not necessarily represent a stable snapshot of the application.

The author_elective_update folder is not created until the initial
commit. That means that in the initial commit you might see files such as
sys_choice files being renamed and moved from the update folder to the
author_elective_update folder. Any files that are deleted from update
sets in historical commits are deleted, and not moved to the
author_elective_update folder as they would be for actual commits.
During the initial commit, DELETE payloads are also created for any DELETE sys_update_xml
records that were deleted as part of completed update sets.  
Example commit message:

    [Historical Commit 1] <Name of update set that this commit belongs to>
    Description: <Description of update set that this commit belongs to>
    Update Set was completed on / installed on <date>
    Update Set was completed by <sys_user user_name > <sys_user email>
    {

Additional values from sys_update_set record (see Customization section below)

    }
    {

Batch update set information: See the Batch update sets section below.

## Batch update sets {#migrate-update-set-history__section_qwc_qbp_rpb}

If an update set is part of a batch update set, that information is appended to the commit
message in the following format, with the highest number being the Batch Base:  

    {
    "1": {
    "parent": "<name of parent update set>",
    "description": "<description of parent update set>"
    },
    "2": {
    "parent": " <name of parent 1's parent update set> ",
    "description": " <description of parent 1's parent update set> "
    }
    }

## Customization {#migrate-update-set-history__section_c5t_xbp_rpb}

You can add additional fields to include in the commit message by adding a
glide.source_control.historical_commit_fields property. The value is a
comma-separated list of fields the user wants to include from sys_update_set XML fields. Spaces
and invalid or misspelled field names are ignored. This property is used for all applications
that are linked to Source Control from the instance if the committer chooses to retain update
set history.  
Nota:  
If the value of a field references another table or sys_id, only the value of the field is added. For example: sys_id for a user instead of the name of the user.
Figura 1. XML example Figura 2. Value of the property Figura 3. Result in commit message