How Do I Keep Track of Different Versions?

Research projects often produce many different outputs, including datasets, documents, software, protocols, figures and publications. All of these can change over time and may require some form of version management. In this guide, however, the focus is on research data and how to keep track of changes made to datasets throughout a project. Many of the principles discussed here can also be applied to other research outputs.

Research data rarely remain unchanged throughout a project. New observations may be added, errors may be corrected, variables may be transformed, records may be removed, and datasets may be combined with other sources of information.

Some of these changes are part of the normal progression of a project. Others can affect how the data should be interpreted, analysed or reused. If these changes are not recorded, it can become difficult to understand how a dataset evolved over time or which version of the data was used to produce a particular result.

Tracking changes helps researchers:

• Understand how a dataset has evolved over time
• Identify which version was used for a publication or analysis
• Recover from mistakes or unintended modifications
• Work more effectively with collaborators
• Support transparency and reproducibility (e.g. Rauber et al., 2016; Johns et al., 2023)

Consider a simple example. A researcher discovers that several records contain errors and corrects them before performing an analysis. Six months later, a collaborator attempts to reproduce the results using an older copy of the dataset and obtains different findings. Without a record of what changed and when, it may be difficult to determine why the results differ.

Tracking changes does not necessarily mean creating a new version every time a file is modified. In many projects, data are continually collected, updated or expanded as part of normal research activities. The more important question is whether a change is significant enough that it should be recorded and distinguishable from earlier versions.

The next sections explore how to make that distinction and how to manage changes to research data in a practical and consistent way.

Research data often change throughout a project. New observations may be added, measurements may be recorded daily, and information may be collected continuously over weeks, months or even years.

However, not every change necessarily creates a new version of a dataset.

For example, imagine a weather station that records temperature every day. Every hour a new observation is added to the dataset.

The dataset has changed, but most researchers would not consider each additional observation to be a new version. The dataset is simply growing as part of the planned data collection process.

The same principle applies to many research projects:

• A survey receives additional responses.
• A new participant is recruited into a study.
• A laboratory records another day's measurements.
• A sensor continues collecting observations automatically.

In these situations, data are being added rather than modified.

However, consider a different situation. After several months, the researchers discover that a calibration error affected all temperature measurements recorded during a particular week. The affected observations are corrected and the dataset is updated.

Although the number of records remains unchanged, the content of the dataset has been modified. Researchers using the corrected data may obtain different results from researchers using the original data. In this case, treating the corrected dataset as a new version may be appropriate.

Similarly, a new version may be justified when researchers:

• Correct errors in existing records
• Remove observations or participants
• Add or remove variables
• Change units of measurement
• Clean or transform the data
• Merge datasets
• Anonymise data before sharing

Different Types of Change

Some changes simply extend a dataset, while others alter information that already exists.

For example:

The distinction is not always absolute, but these examples illustrate an important principle: some changes affect how the data should be interpreted, analysed or reused, while others are simply part of the normal progression of data collection.

A Useful Rule of Thumb

The purpose of versioning is not to record every single modification. Rather, it is to make meaningful states of a dataset identifiable over time. A useful question to ask is:

If the answer is yes, it is often worth considering whether a new version should be created.

Some datasets continue to grow throughout a project. New observations, participants or measurements may be added regularly, making it impractical to create a new version every time the data change.

In these situations, researchers often create snapshots (sometimes called data freezes).

A snapshot is a copy of the dataset captured at a specific point in time. The original dataset may continue to evolve, but the snapshot remains unchanged and can be used for a particular purpose.

For example, a weather monitoring project may collect new measurements every hour. Rather than creating a new version every hour, researchers might create snapshots:

• At the end of each month
• Before a major analysis
• Before submitting a manuscript
• Before sharing the data with collaborators
• Before depositing data in a repository

Each snapshot represents the state of the dataset at a particular moment.

Snapshots are particularly common in projects involving:

• Longitudinal studies
• Clinical research
• Survey data collection
• Environmental monitoring
• Sensor networks
• Large observational datasets

They allow researchers to continue collecting data while preserving the exact dataset used for a specific analysis, publication or report.

A useful way to think about snapshots is that they create stable reference points within a dataset that continues to evolve.

One of the most important decisions in research data management is whether the original data should be modified.

In many projects, researchers collect data and then perform various processing steps before analysis. These may include:

• Correcting errors
• Standardising formats
• Removing duplicate records
• Handling missing values
• Combining datasets
• Calculating new variables
• Anonymising data

After these steps, the dataset may look very different from the data that were originally collected.

For this reason, it is generally good practice to distinguish between raw data and processed data.

Why Keep the Raw Data?

People are sometimes tempted to overwrite the original dataset once cleaning or processing has been completed. However, retaining the original data offers several advantages.

For example, researchers may need to:

• Verify that processing steps were applied correctly
• Correct mistakes introduced during cleaning
• Re-run analyses using different methods
• Respond to questions from collaborators, reviewers or publishers
• Recover information that was removed during processing

Without the original data, these tasks may become difficult or impossible.

A Simple Example

Imagine a spreadsheet containing survey responses.

The original file contains several missing values, inconsistent spellings and duplicate records. A researcher cleans the dataset and produces a new file for analysis.

Instead of replacing the original file, the project might contain:

Project
├── Raw_Data
│   └── Survey_Responses_2026-08-01.xlsx
├── Processed_Data
│   └── Survey_Responses_Cleaned_2026-08-15.xlsx

This approach makes it clear which file contains the original data and which contains the modified version.

Not All Processing Creates a New Dataset

The distinction between raw and processed data is often more useful than creating a long sequence of versions.

For example:

Raw_Data
    Water-Samples.csv

Processed_Data
    Water-Samples_Cleaned.csv

Analysis_Data
    Water-Samples_Analysis.csv

These files may represent different stages of the same workflow rather than successive versions of a single dataset.

Thinking in terms of workflow stages can often be clearer than relying solely on version numbers such as v1, v2 and v3.

Questions to Consider

When working with research data, consider:

• Which files contain the original data?
• Which files have been modified?
• Could the original data be needed again later?
• Can processing steps be explained or reproduced?
• Is it clear which dataset was used for analysis?

Separating raw and processed data helps preserve the original information while making it easier to understand how a dataset evolved throughout a project.

Versioning does not necessarily require specialised software. For many research projects, simple and consistent approaches are sufficient to keep track of different versions of a dataset.

The most important principle is that researchers should be able to identify:

• Which version they are using
• Which version was used for an analysis or publication
• What changed between versions

Version Numbers

One of the simplest approaches is to include a version number at the end of the file name.

For example:

Survey_Data_v01.csv
Survey_Data_v02.csv
Survey_Data_v03.csv

This approach is easy to understand and works well when datasets change occasionally.

However, version numbers are only useful if they are applied consistently. A project that contains files such as:

Survey_Data_Final.csv
Survey_Data_Final_v2.csv
Survey_Data_Final_Really_Final.csv
Survey_Data_Use_This_One.csv

quickly becomes difficult to understand.

Workflow as Versions

As discussed in the previous section, a "version" does not necessarily mean a file named v01, v02 or v03; different stages of a workflow, such as raw, processed and analysis data, can also represent meaningful versions of a dataset.

Dates as Versions

For datasets that are updated regularly, dates are often more informative than version numbers.

For example:

Survey_Data_2026-08-01.csv
Survey_Data_2026-09-01.csv
Survey_Data_2026-10-01.csv

The date immediately indicates when the dataset was created and allows versions to sort naturally in chronological order.

This approach is particularly useful for snapshots and regularly updated datasets.

Combining Versions and Dates

Some projects use both a version number and a date.

For example:

Survey_Data_v01_2026-08-01.csv
Survey_Data_v02_2026-09-15.csv

This can be useful when a dataset is updated frequently but also has important milestone versions. It gives you the ability to quickly search for a file both by version number and/or by date.

Recording What Changed

Version numbers and dates identify different versions, but they do not explain what changed.

For this reason, it can be useful to include in your data management routine the habit of maintaining a simple 'changelog' (you can call it whatever works best for your project) .

For example:

Version 1 (2026-08-01)
- Initial dataset

Version 2 (2026-08-15)
- Corrected missing values
- Removed duplicate records

Version 3 (2026-09-01)
- Added new survey responses
- Standardised variable names

The changelog does not need to be complex. Even a short description can make it much easier to understand the history of a dataset.

Consistency Matters More Than Complexity

Many versioning problems arise not because researchers use the wrong system, but because different people use different systems within the same project.

Whether a project uses version numbers, dates, snapshots or a combination of these approaches is often less important than applying the chosen approach consistently.

A simple system that everyone understands is usually more effective than a sophisticated system that nobody follows.

Questions to Consider

When choosing a versioning approach, consider questions such as:

• How often will the dataset change?
• Are snapshots created at specific milestones?
• Would dates or version numbers be more informative?
• How will changes be documented?
• Will collaborators understand the system being used?

The goal is not to create a perfect versioning scheme, but to make it easy to identify, understand and recover important states of a dataset throughout the project.

Versioning becomes more important when multiple people work with the same data.

Even when researchers follow an agreed versioning convention, collaborative work can still create challenges.

Imagine that two researchers both download Survey_Data_v03.csv from a shared project folder. Each researcher independently makes changes to the dataset and, following the agreed versioning scheme, saves their updated file as Survey_Data_v04.csv.

When they later upload their files to the shared project space, both files have the same name but contain different changes. At this point, it is no longer clear which file should be considered the official version, whether both sets of changes are needed, or how the differences should be reconciled.

This illustrates an important point: file naming conventions help identify versions, but they do not prevent version conflicts when multiple researchers modify the same data simultaneously.

Agree on a Versioning Approach

Collaborative projects benefit from agreeing on a versioning approach before problems arise.

For example, the project team may decide:

• How versions will be named
• When a new version should be created
• How changes will be documented
• Who is allowed to modify the dataset
• How updates will be incorporated into the official project version

The specific system is often less important than ensuring that everyone follows the same approach.

Identify an Authoritative Version

One common source of confusion is the existence of multiple competing copies of the same dataset.

To avoid this, it is useful to identify an authoritative version: the version that should be considered the official project dataset.

Researchers may create temporary copies for analysis, testing or data cleaning, but there should be a clear process for incorporating changes into the authoritative version.

This helps ensure that collaborators are working from the same dataset and reduces the risk of important changes being lost.

Document Important Changes

When datasets are shared between collaborators, recording changes becomes particularly valuable.

As discussed in the previous section, even a simple changelog can help collaborators understand:

• What changed
• Who made the change
• When the change was made
• Why the change was necessary

This can reduce misunderstandings and make it easier to understand how a dataset has evolved over time.

Questions to Consider

When collaborating on research data, consider questions such as:

• Who is allowed to modify the dataset?
• How will new versions be created and named?
• Which version is considered authoritative?
• How will changes be documented?
• Could version conflicts occur if multiple people edit the same data?
• Would snapshots or data freezes be useful?

Versioning in collaborative projects is not simply about creating new file names. It is about ensuring that researchers can understand which dataset should be used, what changed over time and how different contributions fit together.

• Versioning helps researchers track important changes to research data over time.
• Not every change creates a new version. Adding new data is often different from modifying existing data.
• Raw data and processed data should usually be kept separate.
• Dates, version numbers and snapshots can be used to identify meaningful states of a dataset.
• A new version is often justified when changes affect how the data are interpreted, analysed or reused.
• Collaborative projects benefit from agreed versioning practices and clear documentation of changes.
• Specialised tools can help manage version history in projects involving frequent changes or multiple contributors.
• The goal of versioning is to make important versions of a dataset identifiable and understandable over time.

Research Evidence

Johns, M., Meurers, T., Wirth, F., Haber, A., Müller, A., Halilovic, M., Balzer, F., & Prasser, F. (2023). Data Provenance in Biomedical Research: Scoping Review. Journal of Medical Internet Research, 25. https://doi.org/10.2196/42289

Rauber, A., Asmi, A., Uytvanck, D. V., & Pröll, S. (2016). Identification of Reproducible Subsets for Data Citation, Sharing and Re-Use. Bull. IEEE Tech. Comm. Digit. Libr., 12.

Research Infrastructures and Resources

Git. https://git-scm.com/

GitHub. https://github.com/

GitLab. https://gitlab.com/