Development workflow

The day-to-day cycle of getting a change into TensorFlow.

Branches

• master — the main development branch. Most PRs target this.
• rN.M (for example r2.21) — release branches for patch fixes. Created at release-branch-cut and maintained for the lifetime of the release.
• nightly and other tag-driven branches exist to point at well-known build artifacts.

Patch policy is documented in README.md under "Patching guidelines": clone, checkout the release branch, cherry-pick, run tests, build pip from source.

Branch + PR cycle

1. Fork tensorflow/tensorflow on GitHub and clone your fork.
2. git checkout -b my-feature master.
3. Edit code. Run lint, tests (see testing).
4. Push to your fork; open a PR against master.
5. Address review comments. The PR may sit through several rounds before approval.
6. Once approved, a maintainer applies ready to pull (or the bot kicks Copybara directly).
7. Wait for the internal mirror to finish; the PR is auto-closed when the change appears on master.

Copybara — the internal monorepo mirror

TensorFlow is developed on a Google-internal monorepo and exported to GitHub via a tool called Copybara. Conversely, every GitHub PR is mirrored back into the internal repo when it merges. This has several consequences:

• Most master commits are authored by A. Unique TensorFlower <gardener@tensorflow.org> — that's the bot account. Your PR may be one logical change but may show up under that author with the original PR linked in the commit message.
• Some directories are read-only on GitHub: changes here are made internally and exported. tensorflow/compiler/xla/ (now third_party/xla) and large chunks of tensorflow/lite/ are examples.
• Internal-only files (BUILD-time configuration, presubmit infrastructure) sometimes appear and disappear from the tree as Copybara filters change.

If you see a directory where every commit is from the bot, that's typically a strong signal it's primarily maintained internally.

Internal CI (Kokoro) and external CI (GitHub Actions)

• .github/workflows/ — the GitHub Actions workflows run on every PR. They cover formatting, basic builds, and a subset of tests.
• ci/official/ — the configurations Kokoro uses for the heavyweight builds (Linux CPU, Linux GPU, Linux XLA, macOS, Windows, Android, Raspberry Pi).
• ci/devinfra/ — infrastructure scripts for CI maintenance.

A PR can be green on GitHub Actions and still fail Kokoro. Maintainers typically run kokoro:force-run once a PR is approved. If Kokoro fails, the maintainer pastes the failing test names into the PR comment.

Release engineering

• The full release-notes file is RELEASE.md at the root — it is amended in every release PR.
• Release tags (e.g. v2.21.0) are created on the corresponding release branch.
• Pip wheels are built by //tensorflow/tools/pip_package:wheel.
• Versioning is in tensorflow/tf_version.bzl / tensorflow/tf_version.default.bzl.

What to expect on PR latency

CONTRIBUTING.md notes that maintainers may ping you if a PR is awaiting your reply for more than two weeks. Conversely, simple PRs can wait days for first review depending on the area's reviewer load — comp:lite and comp:apis tend to be more responsive than the deeper compiler areas. Internal CI mirroring usually adds a day or two between approval and merge.

Related

• testing — what to run before pushing.
• tooling — bazel, ./configure, generated code.
• patterns-and-conventions — code style.