When portable code meets platform-shaped workflows

A paper about dependency in developer tooling should begin with the strongest evidence against its own thesis. In this case that evidence is Git itself.

The Git documentation describes Git as a distributed version-control system, in which clients do not merely check out the latest snapshot of the files but fully mirror the repository, including its full history (About Version Control). The same documentation states that cloning a repository retrieves a full copy of nearly all data that the server has, and that Git can work with several remote repositories (Getting a Git Repository).

That places an important limitation on everything that follows. A source repository is not inherently bound to a single commercial hosting platform merely because it happens to be hosted there. Ordinary Git repository history is not technically confined to a single hosting provider; Git’s distributed design allows repositories and their history to exist independently of one server. This provides a genuine counterforce to platform dependency, and this paper treats that technical property as established rather than as something to be argued around.

If the repository can move, what surrounds it that may not move as directly?

That is the research question. It is deliberately narrower than the claim that developer tooling has become non-portable, which the available evidence does not support.

Modern development platforms do more than store Git repositories. GitHub is used here as one documented example of the mechanism, not as a special case and not as a target.

GitHub documents GitHub Actions as a way to automate software-development workflows, including continuous integration and continuous delivery, in the repository where the code lives (GitHub Actions documentation). It documents GitHub Marketplace as a place where developers can find Actions and Apps that extend and improve their workflows (About GitHub Marketplace for apps). It documents GitHub Codespaces as cloud-hosted development environments associated with a repository (What are GitHub Codespaces?).

Those are documented product capabilities, stated as such.

Two documented examples are useful, not to compare vendors but to show that CI/CD systems carry their own workflow models and configuration semantics.

GitHub documents Actions as automating software-development workflows in the repository (GitHub Actions documentation). GitLab documents CI/CD configured through a .gitlab-ci.yml file in the repository, in which stages, jobs, scripts, variables, dependencies and conditions define how a pipeline runs (Get started with GitLab CI/CD; CI/CD pipelines).

The System Drift interpretation follows from the shape of that arrangement rather than from any measured outcome. A pipeline file lives beside the source code and travels with the repository when the repository is cloned. The execution model that the file describes — its events, its job semantics, its runner assumptions — belongs to the platform that reads it.

Portable configuration text does not automatically mean portable execution semantics.

Two limits should be stated directly. Nothing here claims that workflows cannot be migrated between these systems; they plainly can be. And System Drift offers no estimate of migration effort, because no evidence available to us would support one.

It is worth separating what is stored inside Git from what is supplied by the surrounding platform. A development workflow may depend on elements such as:

• repository events that trigger automation;
• runner infrastructure that executes jobs;
• secrets and variables held outside the repository;
• permissions and access governance;
• environment configuration;
• platform APIs;
• installed applications;
• deployment integrations.

Which of these apply to any particular team is an organization-specific question, and this list is a map of possible surfaces rather than a claim about prevalence.

None of this suggests that externally executed workflows are undesirable. Hosted execution exists because it removes real operational burden. The question this paper asks is narrower: what would have to be reconstructed if the hosting environment changed?

GitHub documents Marketplace as offering Actions and Apps that developers can use to extend and improve their workflows, with Apps documented as an integration mechanism and Actions as reusable workflow components (About GitHub Marketplace for apps; GitHub Actions documentation).

The structural consequence should be stated carefully. A development environment can accumulate third-party integrations around the repository, and work then passes through those integrations as well as through the repository itself.

The System Drift interpretation: moving source code does not automatically reproduce the surrounding network of integrations through which work is performed. That is a statement about structure, not about difficulty, and it carries no estimate of effort.

An explicit qualification: Marketplace applications are not themselves lock-in. Any dependency arises from an organization’s reliance on particular integrations and interfaces, not from the existence of a marketplace, and reliance is something each organization can observe in its own environment.

GitHub documents Codespaces as cloud-hosted development environments that run in a container on a virtual machine, and documents dev container configuration files committed to the repository as the way a codespace’s environment is defined (What are GitHub Codespaces?; Introduction to dev containers).

This is unusually useful evidence, because it demonstrates portability and platform dependence in the same feature. Configuration-as-code preserves an important part of the development-environment definition inside the repository, where it travels with a clone. The hosted execution of that environment is a platform service.

A development environment can become reproducible without becoming platform-independent.

That nuance is the point of the section, and the acknowledgement runs in both directions. Repository-stored dev container configuration is a genuine counterforce to dependency, and a container-based, specification-driven environment definition is more transferable than an undocumented laptop. Nothing here portrays hosted development environments as restrictive.

The layers can be held together as a chain:

Source code → Repository → Automation → Execution environment → Integrations → Development practice

• source code contains the product or project logic;
• the Git repository preserves source history and other data represented within Git, while collaboration features supplied by the surrounding hosting platform may sit outside that repository;
• automation expresses how code is tested, built or deployed;
• execution infrastructure is what actually performs that automation;
• integrations connect the repository to other tools and services;
• development practice is what a team learns to do around the whole environment.

Git provides unusually strong portability at the left-hand end of this chain. The subject of this paper is what may accumulate further to the right. The same accumulation pattern is examined in a different setting in R-001.

As in R-004, the knowledge layer deserves examination without pretending it has been measured. Working within a particular platform, a team can come to know:

• where workflow failures are surfaced by the platform;
• how permissions interact;
• which automation is dependable;
• how particular Actions, Apps or runners behave;
• where secrets and environments are configured;
• how releases and deployments are operated;
• which platform-specific paths are used during incidents.

No claim is made here about how developers usually or typically behave. The list describes categories of operating knowledge that a platform makes available to be learned; whether and how much any given team holds is not something this paper can establish.

The distinction that follows is the analytical contribution of R-006.

Git provides a strong foundation for the first: a clone carries the repository and its history, and multiple remotes are supported. Git does not itself define the services layered around a hosted repository, and it makes no claim to.

This does not mean workflow migration is impossible. It means that transferring a repository does not on its own establish that the development system has been transferred.

Three papers now carry related lenses, and they should be read as related rather than as a general law. R-004 distinguished telemetry portability from operational portability. R-005 distinguished data portability from analytical portability. R-006 distinguishes repository portability from workflow portability. Each rests on its own evidence, in its own system; the shared shape is an observation, not a proof.

These are diagnostic questions rather than recommendations. Most are answerable from an organization’s own configuration.

• If the repository were cloned elsewhere today, what would immediately work?
• Which CI/CD workflows depend on the current platform’s syntax or event model?
• Where are secrets, variables and environment settings stored?
• Which jobs depend on platform-hosted runners?
• Which Apps, Actions or integrations participate in normal development?
• Which development environments depend on hosted platform services?
• Which configurations are preserved as code inside the repository?
• Which important settings exist only in the platform interface?
• Which deployment or release processes depend on platform APIs?
• What knowledge would a team need to reconstruct before normal development could resume elsewhere?

System Drift attaches no scores to these questions and offers no estimate of exit difficulty. A score here would imply a measurement basis that does not exist.

Git provides a strong technical foundation for source-code and repository portability. The development system surrounding that source code can be less portable, because automation, execution environments, integrations and operating knowledge extend beyond the repository itself.

The interesting question is not “can we move the code?” but “what must be reconstructed before development can continue normally somewhere else?”

This paper makes no claim that developer tooling has been privatized, and no claim that commercial platforms have undermined Git. The opposite pressure deserves explicit acknowledgement: Git’s distributed design, repository-stored pipeline configuration and repository-stored dev container definitions can all support portability and reversibility rather than working against them. The subject here is the tension between those portability mechanisms and the platform layer that grows around them — structural dependency, not vendor intent.

That tension is the substance of F·02 Reversibility and F·05 Exit Complexity: an exit that recovers the code but not the working system is not a completed exit.